Method for managing code analysis tools and their configurations across multiple software projects

Abstract

A computer-implemented method for managing code analysis tools and their configurations across multiple software projects is disclosed. The method comprises: providing a centralized configuration package that includes references to a plurality of code analysis tools and pre-defined configuration settings for the code analysis tools, wherein the configuration package is versioned and stored in a central repository; associating one or more software projects with the centralized configuration package by including a linking reference to the configuration package within a project file of each software project; automatically applying the referenced configuration settings and dependencies defined within the centralized configuration package to each associated software project upon build or analysis by the steps of: adding code analysis tool references and configuration settings to each associated software project; and resolving and managing dependency versions for the code analysis tools according to the version of the centralized configuration package referenced. Unlocking insights from Geo-Data, the present invention further relates to improvements in sustainability and environmental developments: together we create a safe and liveable world.

Description

METHOD FOR MANAGING CODE ANALYSIS TOOLS AND THEIR CONFIGURATIONSACROSS MULTIPLE SOFTWARE PROJECTSFIELD OF THE INVENTION

[0001] The present disclosure generally relates to software development management, and more specifically to a computer-implemented method for managing code analysis tools and their configurations across multiple software projects. Unlocking insights from Geo-Data, the present invention further relates to improvements in sustainability and environmental developments: together we create a safe and liveable world.BACKGROUND OF THE INVENTION

[0002] Software projects typically rely on various configuration files to manage settings that ensure the project functions as intended and adheres to coding standards. Among these settings are configurations for code analysers, which are tools designed to review source code for errors, enforce coding standards, and promote best practices in software development.

[0003] Code analysers help to maintain code quality by identifying potential issues early, suggesting improvements, and enforcing a consistent coding style across a codebase. Their configuration can be extensive, involving numerous rules and settings that can vary depending on the specific requirements of each project. This configuration complexity increases further in large projects or teams where consistent quality and coding standards across multiple repositories are necessary.

[0004] In the .NET development ecosystem, code analysers are widely used to enhance code quality. .NET provides built-in analysers, and developers also commonly integrate third-party or open-source analysers to enforce specific standards or address domain-specific requirements. These analysers are typically integrated into .NET projects as NuGet packages, which are external libraries that provide both the analyser functionality and associated configurations.

[0005] However, the use of multiple code analysers in .NET projects requires carefully managed configuration files, as different analysers may have unique rule sets, versions, and dependency requirements. Additionally, .NET projects often follow strict versioning requirements, especially as newer versions of analysers or .NET itself are released, necessitating frequent updates to these configuration files.

[0006] A problem arises when software projects are divided across multiple repositories. In an initial setup, it is feasible to use a single set of configuration files within a single repository to manage analyser settings uniformly. However, as projects grow and components are moved to separate repositories, each repository needs its own copy of the analyser configuration files. Keeping these configurations consistent across repositories becomes increasingly challenging and error-prone. Manual copying of configurationfiles between repositories not only introduces risks of inconsistency but also adds to maintenance overhead, as updates to configurations or dependencies must be applied separately in each repository.

[0007] A known solution provides guidance on sharing analyser settings within a single repository. However, this approach falls short when applied to multiple repositories, as each repository needs a separate setup and consistent synchronization of configurations.

[0008] Another approach involves using a documented configuration format provided by .NET itself, as described in Microsoft's documentation on configuration options for code analysis. This allows developers to set specific rules for code analysers on a per-project basis. While effective for individual projects, this method requires manually updating configurations for each project or repository, which becomes cumbersome and error-prone in larger, distributed environments where multiple repositories need identical configurations.

[0009] There are also tools available that claim to support configurations across repositories. However, these tools typically still involve copying configuration files into each repository, which can be impractical and difficult to maintain over time.

[0010] Some development teams use GitHub repository templates to initialize new repositories with standardized configuration files. While this approach can help establish initial configurations, it does not provide a mechanism for automatic updates. When configuration files change, teams must manually compare and update files across repositories, leading to potential inconsistencies and significant maintenance overhead.

[0011] In view of the above, there is a need for an improved solution which allows code analyser configurations across multiple repositories to be managed in an improved approach.BRIEF SUMMARY OF THE INVENTION

[0012] In one aspect of the present disclosure, there is provided a computer-implemented method for managing code analysis tools and their configurations across multiple software projects, comprising the steps of:

[0013] - providing a centralized configuration package that includes references to a plurality of code analysis tools and pre-defined configuration settings for the code analysis tools, wherein the configuration package is versioned and stored in a central repository;

[0014] associating one or more software projects with the centralized configuration package by including a linking reference to the configuration package within a project file of each software project; and

[0015] - automatically applying the referenced configuration settings and dependencies defined within the centralized configuration package to each associated software project upon build or analysis by the steps of:

[0016] - adding code analysis tool references and configuration settings to each associated software project; and

[0017] - resolving and managing dependency versions for the code analysis tools according to the version of the centralized configuration package referenced.

[0018] The present disclosure is based on the insight of the inventor that a centralized, version- controlled solution can be used to address the challenge of maintaining consistent code analysis configurations and dependencies across multiple repositories. The inventor realized that such a system would not only simplify the management of code analysis configurations but also improve maintainability and ensure consistency across the entire organization’s codebase, even as projects evolve and scale.

[0019] In the disclosed method, a centralized configuration package acts as a single source of truth, storing the references to code analysis tools and their configuration settings in a versioned format within a central repository. Each project associates with this centralized package by referencing it in its project file. During the build or analysis process, the settings and dependencies defined in the centralized configuration package are automatically applied to the project, ensuring that the code analysis tools are correctly referenced, and their dependencies are resolved in accordance with the specified package version. This eliminates the need for manually managing configuration files across repositories and ensures uniform application of coding standards and rules.

[0020] The disclosed method offers significant benefits for organizations managing multiple repositories. It simplifies configuration management by consolidating settings into a single package, ensuring that updates or changes can be made centrally and propagated automatically across all associated projects. This approach minimizes inconsistencies, reduces maintenance efforts, and enhances code quality by maintaining uniform standards. Additionally, the ability to version-control the configuration package allows organizations to adopt new rules or tool versions seamlessly while retaining the flexibility to roll back if necessary, thereby streamlining development workflows and improving overall efficiency.

[0021] In an example of the present disclosure, the central repository is indicated via a location set in a local configuration parameter.

[0022] This enables a flexible setup where different environments or machines can correctly locate and access the centralized configuration package, improving the portability of the configuration setup.

[0023] In an example of the present disclosure, a version number of the configuration package is indicated in a further local configuration parameter.

[0024] This allows each repository to specify the desired version of the configuration package, facilitating controlled updates across repositories and making it easy to align configurations with specific versions when needed.

[0025] A repository can hold multiple projects, these projects all use the same version. In practice, the version number can be put in a file which is shared amongst all projects. Technically it is also possible to use different versions in different projects.

[0026] In an example of the present disclosure, the linking reference is included through a single-line reference in the project file of each associated software project, wherein the single-line reference specifiesa project type defined by the centralized configuration package, thereby applying a set of pre-defined settings and dependencies for the specified project type.

[0027] This single-line linking referencing approach streamlines setup for new projects, reducing setup complexity and making it easier to standardize configurations across multiple projects.

[0028] In an example of the present disclosure, the method further comprises enabling version updates of the code analysis tools and configuration settings across all associated software projects by updating the version of the centralized configuration package referenced in the repository's configuration file.

[0029] This approach simplifies maintenance and minimizes errors, as updating the version in the repository configuration automatically propagates the update to all associated projects, ensuring consistency.

[0030] In an example of the present disclosure, the centralized configuration package supports both local development environments and cloud-based build environments.

[0031] This feature allows the configuration to be applied seamlessly across different environments without requiring local installation, enhancing compatibility and deployment flexibility.

[0032] In an example of the present disclosure, the centralized configuration package is updated to reflect the latest version of the included code analysis tools and configurations upon release of a new version.

[0033] In practice, new packages need checking to see if any new rules are to be adopted or possibly violating other rules. Therefore, changes to be adopted are decided and then the configuration package is updated manually to implement such changes.

[0034] In an example of the present disclosure, the configuration package allows for the addition of new code analysis rules to be applied across all associated software projects without modifying individual project configurations.

[0035] This capability provides a powerful way to expand rule coverage organization-wide with minimal setup, helping teams enforce new code standards and best practices across all repositories quickly.

[0036] In an example of the present disclosure, the centralized configuration package includes an option for customizing specific rules for individual projects while maintaining a common baseline configuration across all projects.

[0037] This feature allows for flexibility where certain projects require exceptions or specific rules while ensuring a shared baseline configuration, improving adaptability without compromising consistency.

[0038] In an example of the present disclosure, the centralized configuration package supports various code analysis tools and their respective settings.

[0039] This allows organizations to incorporate different analysis tools tailored to specific project requirements, ensuring flexibility while centralizing overall management.

[0040] In an example of the present disclosure, the configuration settings are version-controlled in the central repository such that rollback to previous configurations is possible.

[0041] This version-control capability enables easy restoration of previous configurations if needed, providing reliability and control over project configuration changes.

[0042] In an example of the present disclosure, the configuration package is designed to be compatible with multiple programming languages including C# and VB.NET.

[0043] This broad compatibility allows organizations to use a single configuration package across varied projects, reducing overhead and simplifying configuration management for mixed technology stacks.

[0044] In an example of the present disclosure, the method further comprises using an automated notification system to alert developers of available updates or changes to the centralized configuration package.

[0045] This notification system improves awareness and ensures that developers are informed of the latest configuration changes, facilitating timely updates and ensuring project compliance with current standards.

[0046] According to a second aspect of the present disclosure, a device for managing code analysis tools and their configurations across multiple software projects is provided. The device comprises a processor configured for performing the method according to the first aspect of the present disclosure.

[0047] In a third aspect of the present disclosure, there is provided a computer program product, comprising a computer readable storage medium storing instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to the first aspect of the present disclosure.

[0048] The above mentioned and other features and advantages of the disclosure will be best understood from the following description referring to the attached drawings. In the drawings, like reference numerals denote identical parts or parts performing an identical or comparable function or operation.BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are therefore not to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0050] FIG. 1 schematically illustrates a software project residing in a development environment according to an embodiment of the present disclosure.

[0051] FIG. 2 schematically illustrates, in a flow chart type of diagram, a computer-implemented method for managing code analysis tools and their configurations across multiple software projects according to an embodiment of the present disclosure.DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0052] Embodiments contemplated by the present disclosure will now be described in more detail with reference to the accompanying drawings. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein. Rather, the illustrated embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0053] As can be understood by those skilled in the art, the problem of managing projects distributed across multiple repositories is not unique to the .NET ecosystem. This challenge arises in various scenarios where projects are modularized for scalability, maintainability, or team-based collaboration. For example, in microservices architectures, each service is often developed, tested, and deployed independently, leading to separate repositories for each service. Similarly, large-scale projects that involve multiple teams working on distinct yet interconnected features frequently adopt a multi-repository approach to enable parallel development.

[0054] Another common scenario is in open-source projects, where different components of a software ecosystem, such as libraries, frameworks, and tools, are maintained as separate repositories. Ensuring that all repositories adhere to the same coding standards, dependency versions, and build configurations becomes a significant challenge, especially as the ecosystem grows.

[0055] Similarly, organizations adopting DevOps workflows often use CI / CD pipelines that span multiple repositories, requiring a consistent application of testing frameworks, code analysers, and build tools to ensure high-quality outputs.

[0056] Even in language ecosystems beyond .NET, such as Java (using tools like Maven and Gradle) or JavaScript (using npm or yam), the need to synchronize shared configurations across repositories is a common issue. This is particularly evident when organizations enforce consistent linting, testing, or security scanning rules across projects.

[0057] The following detailed description will focus on examples within the .NET ecosystem. The .NET environment, with its reliance on code analysers, build pipelines, and strict versioning of dependencies, serves as an excellent context to illustrate the principles of centralized configuration management. However, those skilled in the art will understand that the principles described here, such as centralizing configurations, automating updates, and ensuring consistency, are equally applicable to other environments. Whether in Java, Python, JavaScript, or other ecosystems, the methodologies discussed in this disclosure provide a robust solution to a widely encountered problem in modem software development.

[0058] Figure 1 schematically illustrates a software project 120 residing in a development environment 110 according to a first embodiment. The software project 120 is divided into multiple repositories 130, 140 and 150, with respective project directories 131, 141 and 151, 152. A repository can comprise oneproject, such as repository 130, 140, or more than one project, such as repository 150 of Figure 1. A terminal 102 comprising an editor 104 connected to the development environment 110 is also shown in Figure 1.

[0059] In the context of the .NET ecosystem, such a structure is common in large-scale projects where modularization is required to manage complexity and foster independent team workflows. For example, a .NET solution might encompass several microservices or libraries, each housed in its own repository, that is, repositories 130, 140, and 150. These repositories could include specific project directories, such as Proj Directory 131, Proj Directory 141, and Proj Directory 151, 152 that contain the source code, build files, and configurations specific to each module or service. These project directories often need to adhere to a shared set of rules and configurations, such as Roslyn analyser settings, code style enforcement, or dependency management rules, to ensure consistency across the broader project.

[0060] The development environment 110 is typically an integrated development environment (IDE), such as Visual Studio for .NET projects. The terminal 102 and editor 104 provide developers with additional tools for code editing, command-line interactions, and automation tasks, such as building or testing. In this structure, managing and maintaining consistency of configurations, including .NET-specific build tools and code analysers, across repositories becomes a complex challenge, particularly as repositories grow in number or are maintained by different teams.

[0061] This schematic serves as a foundation for understanding the problem of managing configurations and tools across multiple repositories in the .NET ecosystem. The subsequent sections will discuss a centralized approach to address these challenges, ensuring a consistent and maintainable workflow.

[0062] As discussed in the background section, code analysis tools are used in software projects to maintain code quality. Existing solutions for managing the code analysis tools and their configurations across multiple software projects often require local installations or manual copying of configuration files. In the present disclosure, code analysis tools and code analysers are used interchangeably.

[0063] The method of present disclosure addresses the above problem by introducing a centralized configuration package that acts as a single source of truth for code analyser settings and dependencies. The package is stored in a central repository, version-controlled, and accessible to all associated projects.

[0064] Figure 2 schematically illustrates, in a flow chart type of diagram, an embodiment of a computer-implemented method 20 for managing code analysis tools and their configurations across multiple software projects.

[0065] At step 21, a centralized configuration package is provided, the centralized configuration package includes references to a plurality of code analysis tools and pre-defined configuration settings for the code analysis tools. In the present disclosure, the configuration package is versioned and stored in a central repository.

[0066] Dependencies, in this context, refer to the tools and libraries required to execute the code analysis effectively. These dependencies can include company-specific code analysis tools, general- purpose tools like static analysers, and libraries for linting or formatting code. By referencing thecentralized configuration package, these dependencies are automatically included, encompassing tools and packages provided by, for example, Microsoft or third-party vendors.

[0067] The centralized configuration package can be implemented as a tool in the form of a package, which when installed, maintains a coherent set of configuration files in a known location based upon a version number, which can be specified in a local configuration, such asCompanyProjectConfigurationVersion.

[0068] This centralized repository or location can be also set in for example a (further) local configuration, CompanyProjectConfigurationDirectory, which then can be used to reference specific files where needed. This local configuration serves as a pointer to the directory or repository that houses the configuration files. These files are not stored as part of individual user repositories. Instead, all repositories point to the same unified set of files, ensuring consistency across multiple repositories within the organization.

[0069] As an example, the location can be set with the following codes:

[0070] <?xml version— ' 1.0" encoding="utf-8"?>

[0071] <configuration>

[0072] <packageSources>

[0073] <clear / >

[0074] <add key="package 1 " value="https: / / exampleaddres 1 " / >

[0075] <add key="package2" value="https: / / exampleaddress2" / >

[0076] < / packageSources>

[0077] <package Source Mapping>

[0078] <package Source key="packagel">

[0079] <package pattem- 'Company.*" / >

[0080] < / packageSource>

[0081] <package Source key="package2">

[0082] <package pattern- '*" / >

[0083] < / packageSource>

[0084] < / package Source Mapping>

[0085] In the above example, “package 1” can relate to for example a company-specific code analyser, and the URL as designated by exampleaddres 1 tells where the package comprising the relevant configuration settings is. The location as indicated by the HTTPS can point to a webserver on the cloud where the package can be found. The location may also be a directory within a network of the company.

[0086] The “package2” can be a general-purpose package source such as NuGet, in this case, the location as designated by exampleaddres2 can be for example https: / / api.nuget.org / v3 / index.json. The second location serves as a source for obtaining external tools or dependencies beyond the companyspecific configurations. It can be used to get all other package including third party packages other than the company-specific package.

[0087] It is noted that the above defines the location of the package on a central server, it is not the location of the "pointer to the directory" on a local developer's machine. Once the package is installed, a copy is cached on the local machine. That location is the one that needs setting in the Company ProjectConfigurationDirector, which can be set using:

[0088] <CompanyPackageRoot>$(HOME)\.nuget\packages< / CompanyPackageRoot>

[0089] <CompanyProjectConfigurationDirectory>$(CompanyPackageRoot)\company.project.config uration\$(CompanyProjectConfigurationVersion)\build\Configuration< / CompanyProjectConfigurationDir ectory>

[0090] This is a one of as part of the template and does not need changing as it references the CompanyProjectConfigurationVersion variable.

[0091] New rules and / or tools can be added to the centralized configuration package by modifying the source code of the package 1. This means updating version numbers of analysers and configuration of rules or the addition of a new supported project types. When done a new version of this package can be released which then can be used by the projects.

[0092] This means that once a new code analysis rule or dependency is added to the central package, it automatically applies to all associated software projects without requiring manual updates to individual configurations. This feature significantly improves efficiency and reduces overhead when implementing new standards across an organization.

[0093] In addition to maintaining uniformity, the centralized configuration package allows for customization of specific rules for individual projects. For example, while a baseline configuration applies to all repositories, certain projects may require additional or modified rules to suit their specific needs. This flexibility ensures that the centralized system can support a diverse range of projects without imposing unnecessary restrictions.

[0094] As can be contemplated by those skilled in the art, the configuration package can be designed to be compatible with programming languages. This is particularly important in large organizations where teams might work on projects using different languages. While the detailed examples focus on .NET (C# and VB.NET), the principles described are equally applicable to other environments, such as Python, Java, or JavaScript.

[0095] Furthermore, the centralized configuration package is designed to support a variety of code analysis tools and their respective settings. For instance, tools like Roslyn analyzers for .NET, ESLint for JavaScript, or SonarQube for multi-language analysis can be incorporated into the centralized configuration.

[0096] In an example, the version number is defined using the following codes:

[0097] {

[0098] "version": 1,

[0099] "isRoot": true,

[0100] "tools": {

[0101] "company .project.configuration" : {

[0102] "version": "6.0.1",

[0103] "commands": [

[0104] "Company. Project. Configuration"

[0105] ]

[0106] }

[0107] }

[0108] }

[0109] In this example, the configuration version 6.0.1 is specified, which corresponds to a particular set of rules, dependencies, and settings defined in the centralized package.

[0110] Moving to a new version only involves the version number as set above and the Company ProjectConfigurationVersion to the same number. This will then cause Company ProjectConfigurationDirectory to automatically point to a new coherent set of configuration files. [OHl] The configuration settings being version-controlled in the central repository also allow rollback to previous configurations. This is particularly useful when compatibility issues arise after a version update or when teams need to adhere temporarily to an older standard for specific projects.

[0112] At step 22, one or more software projects are associated with the centralized configuration package by including a linking reference to the configuration package within a project file of each software project. This linking reference can be as simple as including a single line in the project file.

[0113] As an example,<hnport Project="$(CompanyProjectConfigurationDirectory) / LibraryPackage .props" / >

[0114] This line points to the centralized configuration directory and automatically associates the project with the relevant configuration settings. The LibraryPackage .props file, for instance, can define dependencies, rules, and build settings for the associated project.

[0115] At step 23, the referenced configuration settings and dependencies defined within the centralized configuration package are automatically applied to each associated software project upon build or analysis. This is specifically realised by the steps of:

[0116] - adding code analysis tool references and configuration settings to each associated software project;

[0117] resolving and managing dependency versions for the code analysis tools according to the version of the centralized configuration package referenced.

[0118] The invention simplifies the management of code analysers, ensuring consistency and maintainability across repositories while supporting seamless updates. This is achieved through a centralized configuration package, version control, and an automated application process that applies consistent rules and settings to all associated projects.

[0119] Based on the abovedescribed method, version updates of the code analysis tools and configuration settings across all associated software projects are realized by updating the version of the centralized configuration package referenced in each repository’s configuration file.

[0120] The method of the present disclosure may further comprise using one or more automated notification system alerts to notify developers of available updates or changes to the centralized configuration package.

[0121] As can be contemplated by those skilled in the art, the centralized configuration package supports both local development environments and cloud-based build environments.

[0122] The centralized configuration package can be automatically updated to reflect the latest version of the included code analysis tools and configurations upon release of a new version. Alternatively, the updated version can also be done manually. This is in consideration that often with newer versions new issues can arise, which might require resolving manually.

[0123] In summary, the disclosed method provides a robust and scalable solution for managing code analysis tools and configurations across multiple software projects. By centralizing configurations, automating dependency management, and supporting version control, the invention simplifies project setup, enforces coding standards, and ensures consistency across an organization’s repositories.

[0124] The invention has been described by reference to certain embodiments discussed above. It will be recognized that these embodiments are susceptible to various modifications and alternative forms well known to those of skill in the art.

[0125] Further modifications in addition to those described above may be made to the structures and techniques described herein without departing from the spirit and scope of the invention. Accordingly, although specific embodiments have been described, these are examples only and are not limiting upon the scope of the invention.

Claims

CLAIMS1. A computer-implemented method for managing code analysis tools and their configurations across multiple software projects, comprising: providing a centralized configuration package that includes references to a plurality of code analysis tools and pre-defined configuration settings for the code analysis tools, wherein the configuration package is versioned and stored in a central repository; associating one or more software projects with the centralized configuration package by including a linking reference to the configuration package within a project file of each software project; automatically applying the referenced configuration settings and dependencies defined within the centralized configuration package to each associated software project upon build or analysis by the steps of: adding code analysis tool references and configuration settings to each associated software project; resolving and managing dependency versions for the code analysis tools according to the version of the centralized configuration package referenced.

2. The method according to claim 1, wherein the central repository is indicated via a location set in a local configuration.

3. The method according to claim 1 or 2, wherein a version number of the configuration package is indicated in a further local configuration.

4. The method according to any of the previous claims, wherein the linking reference is included through a single-line reference in the project file of each associated software project, wherein the single- line reference specifies a project type defined by the centralized configuration package, thereby applying a set of pre-defined settings and dependencies for the specified project type.

5. The method according to any of the previous claims, further comprising: enabling version updates of the code analysis tools and configuration settings across all associated software projects by updating the version of the centralized configuration package referenced in each project's configuration file.

6. The method according to any of the previous claims, wherein the centralized configuration package supports both local development environments and cloud-based build environments.

7. The method according to any of the previous claims, wherein the centralized configuration packageis updated to reflect the latest version of the included code analysis tools and configurations upon release of a new version.

8. The method according to any of the previous claims, wherein the configuration package allows for the addition of new code analysis rules to be applied across all associated software projects without modifying individual project configurations.

9. The method according to any of the previous claims, wherein the centralized configuration package includes an option for customizing specific rules for individual projects while maintaining a common baseline configuration across all projects.

10. The method according to any of the previous claims, wherein the centralized configuration package supports various code analysis tools and their respective settings.

11. The method according to any of the previous claims, wherein the configuration settings are version- controlled in the central repository such that rollback to previous configurations is possible.

12. The method according to any of the previous claims, wherein the configuration package is designed to be compatible with programming languages including C# and VB.NET.

13. The method according to any of the previous claims, further comprising: using one or more automated notification system alerts to notify developers of available updates or changes to the centralized configuration package.

14. A device for managing code analysis tools and their configurations across multiple software projects, comprising a processor configured for performing the method according to any of the previous claims 1 to 13.

15. A computer program product, comprising a computer readable storage medium storing instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the pervious claims 1 to 13.

Images