Method for estimating the performance of a software architecture formed by a set of hardware and software blocks, device and associated method

Abstract

Method for estimating the performance of a software architecture formed by a set of hardware and software blocks, associated device and method. The present invention relates to a method for estimating the performance of a software architecture (40) formed by at least one hardware block (44) and at least one software block (46) comprising a step of: - receiving a set (42) of blocks (44, 46) forming a software architecture (40), - obtaining the elementary efficiency of the block (44, 46) by reading a first database associating an elementary efficiency with each block, - determining at least one elementary performance indicator distinct from the efficiency by reading in a second database associating at least one elementary performance indicator with each said block, and - estimating the performance of the software architecture (40) from the elementary efficiencies obtained and the elementary performance indicators.Figure for the abbreviation: figure 3.

Description

Title of the invention: Method for estimating the performance of a software architecture formed by a set of hardware and software blocks, associated device and method

[0001] The present invention relates to a method for estimating the performance of a software architecture formed by a set of blocks. It also relates to a method for implementing a software architecture. The invention also relates to an associated estimation system.

[0002] Nowadays, due to the problems surrounding global warming, a new requirement has developed in multiple technical fields, often summarized under the English term "sustainability" which can be translated as durability, sustainability or efficiency.

[0003] This applies in particular to software architectures that we seek to make more environmentally friendly, and in particular more frugal in consumption.

[0004] However, the assessment of this respect for the environment is complex for a software architecture since a software architecture involves many elements, including hardware elements (memories and processors in particular), contributing to the ecological footprint of the overall architecture in a dependent manner.

[0005] In other words, it is not enough to reduce the ecological footprint of each of the elements taken individually to reduce the ecological footprint at the level of the software architecture.

[0006] There is therefore a need for a process enabling an estimation of the performance of a software architecture taking into account this complexity.

[0007] To this end, the description relates to a method for estimating the efficiency of a software architecture formed by a set of blocks, the set of blocks comprising at least one hardware block and at least one software block, the estimation method being implemented by an estimation system, the estimation method comprising:

[0008] - a step of receiving a set of blocks forming a software architecture,

[0009] - for each of the blocks, a step of obtaining the elementary efficiency of the block by reading a database, the database associating each block likely to be part of a software architecture with a basic efficiency,

[0010] - for each of the blocks, a step of determining the relative contribution of each block contributes to the efficiency of the software architecture, and

[0011] - a step of estimating the efficiency of the software architecture from the elementary efficiencies obtained and relative contributions determined.

[0012] In other words, a method and formulation for measuring the energy efficiency of an architecture is proposed, based on a textual and / or graphical description of that architecture reflecting the choices and decisions made. For each block of the architecture, as well as their connections, a measurement is performed based on a set of native properties and configurations made by the architect, depending on the type of block and the chosen solution. Not all properties have the same impact, and therefore an initial weighting is applied in our calculation. A second weighting is then applied to take into account the use case, the type of load, the types of exchanges, and more generally, the context, which can change the importance of certain parameters.

[0013] Corrective factors such as architectural style, the suitability of a block in this style and with other blocks are then considered.

[0014] Thus, according to other advantageous aspects, the estimation method comprises one or more of the following features, taken individually or in all technically possible combinations:

[0015] - during the determination step, the relative contribution depends on the use of the block by software architecture.

[0016] - the process further comprises, for each of the blocks, a calculation step of a parameter representative of the integration of the block into the set of blocks, the estimation step also taking into account the parameters representative of the integration.

[0017] - during the estimation step, the sum of the elementary efficiencies is calculated obtained weighted by the determined relative contributions, the efficiency depending on the result of the calculated sum.

[0018] - the process includes a step of obtaining a representative correction coefficient of the type of software architecture.

[0019] - at least one software block is chosen from the list consisting of a calculation block, of a security block, a memory block, an interface block, a network block and a content delivery network block.

[0020] - at least one hardware block is chosen from the list consisting of an interface application programming, an application programming interface gateway, a service mesh, an inference model, a foundation model, and a scheduler.

[0021] - efficiency is a measure of consumption.

[0022] The description also relates to a method for implementing a software architecture formed by a set of blocks, the set of blocks comprising at least one hardware block and at least one software block, the method comprising:

[0023] - a step in implementing the estimation method as previously described on a set of candidate software architectures, to obtain the efficiency of each candidate software architecture,

[0024] - a step of selecting the candidate software architecture exhibiting the efficiency the highest, and

[0025] - a step in realizing the selected software architecture.

[0026] The description also relates to a system for estimating the efficiency of a software architecture formed by a set of blocks, the set of blocks comprising at least one hardware block and at least one software block, the estimation system comprising:

[0027] - a receiving module, the receiving module being suitable for receiving a set of blocks forming a software architecture

[0028] - a memory module, the memory module being suitable for memorizing a database associating each block likely to be part of a software architecture with a basic efficiency

[0029] - a obtaining module, the obtaining module being specific to, for each of the blocks, obtain the elementary efficiency of the block by reading the database,

[0030] - a determination module, the determination module being specific to, for for each of the blocks, determine the relative contribution of each block to the efficiency of the software architecture, and

[0031] - an estimation module, the estimation module being suitable for estimating efficiency of the software architecture based on the elementary efficiencies obtained and the relative contributions determined.

[0032] To this end, the description relates to a method for estimating the performance of a software architecture formed by a set of blocks, the set of blocks comprising at least one hardware block and at least one software block, the estimation method being implemented by an estimation system, the estimation method comprising:

[0033] - a step of receiving a set of blocks forming a software architecture,

[0034] - for each of the blocks, a step to obtain the elementary efficiency of the block by reading a first database, the first database associating with each block likely to be part of a software architecture an elementary efficiency,

[0035] - for each of the blocks, a step of determining at least one indicator of elementary performance, at least one elementary performance indicator being distinct from efficiency, the determination step is implemented by reading from a second database, the second database associating with each block likely to be part of a software architecture said at least one elementary performance indicator, and

[0036] - a step of estimating the performance of the software architecture from the elementary efficiencies obtained and elementary performance indicators.

[0037] According to other advantageous aspects, the estimation method comprises one or more of the following features, taken individually or in all technically possible combinations:

[0038] - the second database is a decision table.

[0039] - the determination step is carried out by interaction of the estimation system with an application programming interface.

[0040] - at least one performance indicator is chosen from the list constituted by a a safety indicator, a reliability indicator and a quality indicator.

[0041] - the performance indicators determined at the determination stage are a a safety indicator, a reliability indicator, a performance indicator and a quality indicator.

[0042] - the estimation step includes an aggregation of the elementary efficiencies for to achieve overall efficiency.

[0043] - for each performance index, the estimation step includes an aggregation elementary performance indicators to obtain an overall performance index.

[0044] - each aggregation is implemented for only a portion of the blocks of the set of blocks.

[0045] The description also relates to a method for implementing a software architecture formed by a set of blocks, the set of blocks comprising at least one hardware block and at least one software block, the method comprising:

[0046] - a step in implementing the estimation method as previously described on a set of candidate software architectures, to obtain the efficiency of each candidate software architecture,

[0047] - a step of selecting the candidate software architecture presenting the highest performance, and

[0048] - a step in implementing the selected software architecture.

[0049] The description also relates to a system for estimating the performance of a software architecture formed by a set of blocks, the set of blocks comprising at least one hardware block and at least one software block, the estimation system comprising:

[0050] - a receiving module, the receiving module being suitable for receiving a set of blocks forming a software architecture

[0051] - a memory module, the memory module being suitable for memorizing a first database associating each block likely to be part of a software architecture with a basic efficiency,

[0052] - a obtaining module, the obtaining module being specific to, for each of the blocks, obtain the elementary efficiency of the block by reading the first database,

[0053] - a determination module, the determination module being specific to, for for each of the blocks, determine at least one elementary performance indicator, the at least one elementary performance indicator being distinct from efficiency, the module determining the at least one elementary performance indicator by reading from a second database, the second database associating with each block likely to be part of a software architecture said at least one elementary performance indicator, and

[0054] - an estimation module, the estimation module being suitable for estimating the software architecture performance based on elementary efficiencies obtained and elementary performance indicators.

[0055] In this description, the expression "specific to" means interchangeably "suitable for", "adapted to" or "configured for".

[0056] The invention will become clearer upon reading the following description, given solely by way of non-limiting example, and made with reference to the drawings in which:

[0057] - [Fig.1] [Fig.1] is a schematic representation of a flowchart corresponding to an example of the implementation of a method for estimating the efficiency of a software architecture,

[0058] - [Fig.2] [Fig.2] is a schematic representation of an estimation system the efficiency of a software architecture,

[0059] - [Fig.3] [Fig.3] is a schematic representation of the structure of a software architecture,

[0060] - [Fig.4] [Fig.4] is a schematic representation of an example of architecture software on which the efficiency estimation process is implemented,

[0061] - [Fig.5] [Fig.5] is a schematic representation of a flowchart corresponding to an example of the implementation of a software architecture design process,

[0062] - [Fig.6] [Fig.6] is a schematic representation of a flowchart corresponding to an example of implementing a method for estimating the performance of a software architecture, and

[0063] - [Fig.7] [Fig.7] is a schematic representation of an estimation system the performance of a software architecture.

[0064] Fig. 1 is a schematic representation of a flowchart corresponding to an example of the implementation of a method for estimating the efficiency of a software architecture.

[0065] The estimation process aims to obtain an efficiency value.

[0066] According to the example described, efficiency is a measure of resource use, for example expressed in terms of consumption.

[0067] Typically, using 200 GB for one hour leads to consuming less than 100 GB for 10 hours.

[0068] In the following, for the sake of exemplification and clarity for the reader, instead of using the term efficiency, the term consumption will be used.

[0069] The estimation process is implemented by an efficiency estimation system 10 represented in [Fig.2].

[0070] The estimation system 10 comprises a receiving module 12, an obtaining module 14, a determining module 16 and an estimation module 18.

[0071] In the example of [Fig.2], the estimation system 10 includes an information processing unit formed for example of a memory and a processor associated with the memory.

[0072] According to this example, the receiving module 12, the obtaining module 14, the determining module 16, and the estimating module 18 are each implemented as a software program, or a software component, executable by the processor. The memory of the estimating system 10 is then capable of storing a receiving software program, a obtaining software program, a determining software program, and an estimating software program. The processor is then capable of executing each of the following software programs: the receiving software program, the obtaining software program, the determining software program, and the estimating software program.

[0073] In an alternative not shown, the receiving module 12, the obtaining module 14, the determining module 16 and the estimating module 18 are each made in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array), or an integrated circuit, such as an ASIC (Application Specified Integrated Circuit).

[0074] When the estimation system 10 is implemented in the form of one or more software programs, i.e., in the form of a computer program, also called a computer program product, it is further capable of being stored on a computer-readable medium, not shown. A computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. By way of example, a readable medium is an optical disc, a magneto-optical disc, ROM, RAM, any type of non-volatile memory (e.g., FLASH or NVRAM), or a magnetic card. A computer program containing software instructions is then stored on the readable medium.

[0075] The estimation system 10 further comprises a storage module 20.

[0076] The role of each of the modules 12, 14, 16, 18 or 20 will appear in the rest of the description in light of the description of the implementation of the estimation process.

[0077] According to the example in [Fig.1], the estimation process comprises a receiving step E30, a obtaining step E32, an estimation step E34, a determination step E36 and an estimation step E38.

[0078] During the reception step E30, the reception module 12 receives a software architecture 40 as shown in [Fig.2].

[0079] The software architecture 40 is formed by a set of blocks 42 of which at least one hardware block 44 and at least one software block 46.

[0080] More precisely, the set 42 comprises a first subset 48 grouping the hardware blocks 44 and a second subset 50 grouping the software blocks 46.

[0081] Only two blocks are represented in each of subsets 48 and 50, this number not being limiting.

[0082] The interaction between the two subsets 48 and 50 allows the software architecture 40 to perform the function(s) that it implements.

[0083] At least one hardware block 44 is chosen from the list consisting of the following blocks: • computing unit (processor, CPU, GPU), • safety block, • database management block, • interface block, • memory block, • storage unit (hard drive, SSD, magnetic tape), • network block, • data processing block, • content delivery network block, and • firewall block

[0084] In the previous list: • The abbreviation CPU refers to the English term "central processing unit," which literally means central processing unit. • The abbreviation GPU refers to the English term "graphics processing unit," which literally means graphics processing unit. • The abbreviation SSD refers to the English term "solid-state drive," which is often translated as semiconductor disk, and • A content delivery network is more often referred to by the abbreviation CDN, which refers to the corresponding English term "content delivery network".

[0085] At least one software block 46 is chosen from the list consisting of: • application programming interface (more often referred to by the abbreviation API, which refers to the corresponding English term "Application Programming Interface"), • application programming interface gateway (more often referred to by the abbreviation API gateway in reference to the corresponding English term), • service mesh (more often referred to by the corresponding English term "service mesh"), • foundation model, notably the LLM model (which refers to the English term 'large language model' which literally means large language model), • inference engine, • Web server, • event bus (often referred to by the corresponding English name) of “event bus”), • graphical user interface (more often referred to by the abbreviation GUI, referring to the corresponding English term "graphical user interface"), • hidden, • load balancer (also known by the English term "load distributor"), • Log management (also referred to by the English term "Log management"), • scheduler (often referred to by the corresponding English term "scheduler"), • microservices (sometimes referred to as a "microservices framework") • serverless environment (also referred to by the English term "serverless framework"), • container (more often referred to by its corresponding English name, "Container"), and • virtual machine.

[0086] The E32 obtaining step is implemented for each of the blocks 44 or 46 of the received software architecture 40.

[0087] During this step E32, the obtaining module 14 obtains the elementary consumption of block 44 or 46.

[0088] For this purpose, the retrieval module 14 reads a database stored in the storage module 20.

[0089] The database associates each block that could be part of a software architecture with an elementary consumption.

[0090] The database was established before the implementation of the process.

[0091] Elementary consumption is based on taking into account a set of dimensions leading to an increase in elementary consumption.

[0092] These dimensions are, for example, the following: • Transport: This refers to the transport of data, which should be limited. • inventory: this concept aims to take into account the memorization of data, whether in databases or code, • Latency: This refers to the fact that software waiting for a response or processing consumes resources, particularly memory resources. • Overproduction: This concept aims to limit the data produced in order to produce or transmit only the useful data. • Over-processing: This refers to considering the usefulness of the processing performed. As a specific example, a compression ratio of 1.1 or lower indicates that the compression operation involved over-processing. • failure: this concept takes into account the ecological impact of handling errors, bugs and / or failures.

[0093] By evaluating each of these dimensions, it is possible to obtain an elementary consumption for each block thanks to the knowledge of an expert.

[0094] The determination step E34 is implemented for each of the blocks 44 or 46 of the received software architecture 40.

[0095] During this step E34, the determination module 16 obtains the relative contribution of each block 44 or 46 to the consumption of the software architecture 40.

[0096] This contribution is determined by an upstream analysis during which the relative contribution in the presence of the other blocks is evaluated.

[0097] Typically, a software block that is very demanding in terms of memory will have a greater weighting in the presence of a block that is not very demanding in terms of memory compared to the case where the software block is in the presence of an extremely demanding software block.

[0098] The estimation module 18 then implements the estimation step E36 to obtain an estimate of the consumption of the software architecture 40.

[0099] For this purpose, the estimation module 18 is based on the elementary consumptions and the determined relative contributions.

[0100] More specifically, the estimation module 18 applies an estimation function taking as input at least the elementary consumptions and the determined relative contributions.

[0101] According to an example, the estimation function is suitable for calculating the sum of the elementary consumptions obtained weighted by the relative contributions determined.

[0102] Mathematically, this is written: [° 103 L

[0104] Where: • C denotes the value of the software architecture's power consumption, • n denotes the number of blocks, • i denotes the relative contribution of block i, and • âj denotes the elementary consumption of block i.

[0105] By way of particular illustration, all the elementary contributions and consumptions are obtained such that the sum involved in the calculation of the estimation function is less than or equal to 100, that is to say:

[0106] 2^^100

[0107] According to a more elaborate embodiment, as indicated above, the relative contribution depends on the use of block 44 or 46 by the software architecture 40.

[0108] In such a case, the expression for the estimation function then becomes:

[0109] (j = U

[0110] Where u denotes use.

[0111] Such a weighting can be described as contextual weighting.

[0112] To illustrate its interest, the case of an application programming interface can be considered.

[0113] APIs have the particularity of being bidirectional, that is to say that messages can be sent from both ends at the same time and it is therefore necessary to take into account the consumption of both ends.

[0114] However, a protocol may be used where this simultaneity is not permitted, for example a protocol allowing a response from the server only in the presence of a request from a client.

[0115] In such a case, the context of use means that the weighting of the API should be reduced in this particular case.

[0116] Hence the interest of the previous estimation function.

[0117] According to yet another embodiment, the process further comprises, for each of the blocks 44 or 46, a calculation step of a parameter representative of the integration of block 44 or 46 into the set 42 of blocks.

[0118] The estimation function then takes into account the representative parameters of the integration thus obtained.

[0119] For example, the estimation function can be written mathematically as follows:

[0121] Where If denotes the parameter representing the integration of block i.

[0122] To give an example in which such a formulation is useful, one can cite the case of a serverless architecture (more commonly referred to by the English term "serverless") in which a software block is intended to be used efficiently with a server. In such a case, the efficiency value should be reduced.

[0123] As an alternative or in addition, the process may also include a step of obtaining a correction coefficient representative of the type of software architecture.

[0124] A monolithic architecture, a microservices architecture or a serverless architecture are examples of architecture types.

[0125] Denoting S as such a correction coefficient, an expression for the estimation function taking into account all the elements described above is as follows:

[0126] c = + S

[0127] It may be noted that, in each of the preceding cases, the sum of the elementary consumptions obtained is calculated weighted by the relative contributions determined, the estimated consumption depending on the result of the calculated sum.

[0128] A particular example of implementation of the estimation process is now described with reference to [Fig.4] which illustrates a software architecture to be evaluated.

[0129] In this figure, the software architecture 40 is described here in the form of an ArchiMate model but any form of description could be accepted.

[0130] The software architecture 40 includes a scheduler 52 (more commonly called a scheduler), a web client 54, an allocation application 55, an activity database 56, an API 58 and a payroll management block 60.

[0131] Software architecture 40 is an application for managing the activities of employees of a company on different projects.

[0132] It may be noted that, as this is a web application, users do not have to install anything on their computer.

[0133] The application is a Java application of the Web application type. This application therefore runs in a Java web server, in this case Tomcat, which serves JSP pages (for "Java Server Page" literally "Java server page") to the client.

[0134] As regards the database, it is an Oracle database which is embedded in a VMware virtual machine on a dedicated server.

[0135] This database has three different schemas, that is to say that this database serves three other application databases in parallel.

[0136] The data is updated by a JTime application using Hibernate software.

[0137] From a hardware perspective, this is a Java application with the OpenJDK JRE, JRE standing for Java Runtime Environment and JDK for the corresponding development environment. The application runs on an Apache Tomcat web server and connects to the database via Hibernate.

[0138] Software architecture 40 also includes an HTTP server (Apache HTTP Server) which serves as a reverse proxy and load regulator.

[0139] In this example, the set of blocks is obtained by using a named entity recognition tool.

[0140] Such a tool is more often called NER in reference to the corresponding English term "Named Entity Recognition".

[0141] Such a tool also makes it possible to extract the role of the different blocks.

[0142] In the specific example described here, this leads to obtaining the following list of blocks: • Oracle - Relational Database • Tomcat - Java web server, Servlet and JSP engine • VTom - Enterprise scheduler • Hibernate - ORM (Object Relational Mapping) • APIs

[0143] The format in which the corresponding model is generated is irrelevant.

[0144] For example, the format may be a DAT format (for "technical architecture document"), an ADR format (for "Architecture Decision Record") or an SDD format (for "Software Design Document").

[0145] The reception step E30 of the process can thus be carried out by receiving the blocks of the software architecture thus obtained.

[0146] The E32 obtaining step will then be implemented using the database which associates an elementary efficiency with each block.

[0147] To better understand how to achieve such elementary efficiency, some elements to be taken into account when establishing such a database are now described.

[0148] In the following, this explanation is qualitatively described for the case of the Oracle database.

[0149] This database is a relational database, which is often referred to as RDBMS (for the corresponding English name of "Relational Data Base Management System") and OLTP (for the corresponding English name of "Online Transaction Processing").

[0150] Several elements influencing the efficiency of this database are now described, bearing in mind that this list is not necessarily exhaustive.

[0151] Language is a first example of an element influencing efficiency in this context.

[0152] This is the programming language in which this database is written.

[0153] This property is notably used for its impact on memory footprint. Indeed, a language like Java can involve 15 times more memory requirements than a database written in Rust.

[0154] Knowing that the more memory is used, the more energy is consumed and therefore the greater the need for heavy configurations and servers, so that the language is well linked to the ecological impact.

[0155] A second example is the ability of a database to accommodate several types of databases.

[0156] For example, one type is OLTP (which refers to the corresponding English name of "OnLine Transactional Processing") operating by transactional processing) and another type is OLAP (which refers to the corresponding English name of "OnLine Analytical Processing") operating by analytical processing.

[0157] Indeed, such a capability makes it possible to avoid the use of two different databases.

[0158] A third example is the efficiency of queries in the database

[0159] In fact, this efficiency greatly impacts CPU usage and disk access, which has a strong impact on the environmental footprint of the database.

[0160] A fourth example is whether the database is natively constructed as a distributed database or not.

[0161] A fifth example is the possibility of performing processing in memory or not. In fact, having such a capacity allows for a reduction in disk accesses.

[0162] A sixth example is the way in which transactions are managed.

[0163] Indeed, transaction management specific to OLTP databases is crucial, particularly from a resource consumption point of view, and good management makes it possible to limit both the use of the processor and memory.

[0164] A seventh example is the management of concurrent access.

[0165] Yet another example is the ability or inability to perform an automatic adjustment performance. This notably allows for a significant improvement in indexing capabilities.

[0166] Such a method therefore makes it possible to estimate the power consumption of a software architecture with good accuracy without having to manufacture it. In particular, no physical measurements are taken.

[0167] In this sense, the process can be seen as a technique for evaluating the qualitative eco-design score of a software architecture.

[0168] This is particularly advantageous in design to be able to test multiple software architectures.

[0169] Thus, the estimation process just described is advantageously used in a process for realizing a software architecture formed by a set of blocks, as schematically illustrated by [Fig.5].

[0170] The implementation process comprises an implementation step E70, a selection step E72 and an implementation step E74.

[0171] During the implementation step E70, the estimation system 10 implements the previous estimation process on a set of 40 candidate software architectures.

[0172] This means that the steps of the estimation process are implemented iteratively, each iteration corresponding to a respective candidate software architecture 40.

[0173] Thus, at each iteration, the estimation system 10 obtains the consumption of a candidate software architecture.

[0174] The selection step E72 is a selection step of a candidate software architecture 40 based on the consumptions estimated in the estimation step E70.

[0175] For this purpose, according to the example described, the software architecture corresponding to the highest consumption is selected.

[0176] During implementation step E74, the software architecture 40 thus selected is implemented.

[0177] The realization may vary depending on the embodiment.

[0178] According to a first example, the realization is a fabrication of the set 42 of the blocks, so that the software architecture 40 is physically available and therefore ready to be used by a user.

[0179] In practice, the hardware blocks 44 are manufactured or obtained from a supplier, then the software blocks 46 are loaded onto the hardware blocks 46 enabling them to be implemented.

[0180] According to a second example, the implementation consists of entering the selected blocks 44 or 46 into a simulation tool to determine other performance indicators of the software architecture 40, and in particular to determine whether the software architecture 40 is suitable for the intended use. The process then serves to evaluate a qualitative eco-design score of a software architecture 40 prior to its implementation.

[0181] Alternatively, instead of carrying out two separate phases, consideration may be given to determining these performance indicators at the same time as efficiency.

[0182] Figure 6 illustrates an example of the implementation of such an estimation method.

[0183] The estimation process aims to estimate a performance value.

[0184] For this purpose, the estimation process includes a receiving step E80, a obtaining step E82, a determination step E84 and an estimation step E86.

[0185] The E80 acceptance step is similar to the E30 acceptance step, so the same remarks as before apply.

[0186] The obtaining step E82 is similar to the obtaining step E32, so the same remarks as before apply.

[0187] The database used during this step E82, that is to say the database associating with each block likely to be part of a software architecture an elementary efficiency, is denoted the first database in the following.

[0188] During the determination step E84, at least one elementary performance indicator is determined for each of the blocks 44 or 46.

[0189] The elementary performance indicator is distinct from an efficiency indicator.

[0190] For example, the performance indicator is chosen from a safety indicator, an indicator of reliability and an indicator of quality.

[0191] The determination step E84 is implemented by reading from a second database.

[0192] The second database associates with each block likely to be part of a software architecture said at least one elementary performance indicator.

[0193] In the example described, the first database and the second database are distinct, but it is also possible that the two databases are confused, the information read in steps E82 and E84 simply coming from a different column.

[0194] In this embodiment, the second database is, for example, a decision table.

[0195] The second database was established prior to the implementation of the estimation process by collecting knowledge from an expert.

[0196] Typically, for each block 44 or 46, it is indicated whether the impact is positive, neutral or negative for the performance indicator considered.

[0197] Following the implementation of the determination step E84, for each block 44 or 46, an elementary efficiency value and a value for the elementary performance indicator.

[0198] During the estimation step E86, the performance of the software architecture 40 is estimated from the elementary efficiencies obtained and the elementary performance indicators.

[0199] According to one example, the estimation step E86 includes an aggregation of the elementary efficiencies to obtain an overall efficiency.

[0200] Similarly, the estimation step E86 includes an aggregation of the elementary performance indices to obtain an overall performance index.

[0201] This aggregation is implemented for each performance indicator that we wish to evaluate.

[0202] According to an advantageous embodiment, performance is evaluated by applying an estimation function to overall efficiency and at least one overall performance index.

[0203] The estimation function is, for example, a sum weighted by weighting coefficients whose value depends on the requirements desired for the software architecture 40.

[0204] Typically, if the software architecture 40 is a critical system, reliability is paramount and takes precedence over efficiency, so that the reliability weighting coefficient is much higher than the efficiency weighting coefficient.

[0205] Such a process thus makes it possible to evaluate the performance of a software architecture 40 by determining the frictions between performance indicators and efficiency.

[0206] The value of determining such frictions will become clearer through concrete examples where such an estimation method can be used. These examples are now briefly described.

[0207] A first example is that of data transmission and compression. Indeed, it is rightly recommended to limit the volumes of data that are transmitted over the network.

[0208] This principle therefore leads to wanting to compress data, which will effectively limit the volume of data transmitted and therefore the resulting carbon footprint.

[0209] However, compressing data also has an energy cost. Moreover, if compression occurs at the source, decompression is generally required at the destination, and therefore this also has an energy cost.

[0210] The decision to compress is therefore not as trivial as it might seem; several elements must be considered, including the volume of data, their type (binary or textual), their representation (e.g. XML or JSON or ProtoBuf), the distance to travel, the algorithm used, or whether the data is encrypted or not.

[0211] A second example is that of data encryption which involves a friction between security and efficiency.

[0212] Encryption is a mathematical operation that consumes a significant amount of processor power. Moreover, for data that is frequently accessed for reading, it is necessary to decrypt systematically, and if the encrypted data is modified, it must be re-encrypted before being saved.

[0213] It can be noted that this problem could be circumvented by keeping a decrypted version in cache, but then the benefit of encrypting the data from a security point of view is lost.

[0214] It will therefore be useful to find a compromise between security and consumption depending on the nature of the data and the frequency of access to this data.

[0215] Similar considerations apply to history, traceability or weighted auditing.

[0216] However, other examples can be cited with regard to the safety / durability friction.

[0217] Thus, certain approaches or types of containers can induce vulnerabilities.

[0218] Another aspect is measurement. In fact, to limit consumption, it is necessary to monitor consumption in real time.

[0219] However, the measurement tools themselves can sometimes disrupt security, notably by increasing the attack surface.

[0220] To better illustrate the complexity of taking into account the different parameters, it can also be recalled here that it is possible to gain both in safety and efficiency.

[0221] Indeed, by avoiding anything unnecessary in the software architecture (unused lines of code or unnecessary hardware), there is a gain in efficiency and a reduction of the attack surface, thus limiting vulnerabilities.

[0222] Another example is redundancy, which increases reliability but decreases efficiency.

[0223] Typically, having two datacenters in a software architecture, whether in active or passive mode, leads to consuming more energy than one.

[0224] The right balance will depend on several parameters including the nature of the system, the type of data hosted, the average carbon consumption in the different datacenters, the distance separating the datacenters, the probability of occurrence of dangerous natural events or the probability of an attack.

[0225] These observations also concern servers, power supplies, firewalls, data, and backup(s).

[0226] Quality and efficiency can also generate friction.

[0227] For example, the precision of a calculation can be reduced by delivering an integer instead of a decimal number or by broadcasting a black and white video instead of a color video.

[0228] Along the same lines, it is possible to group the treatments into a batch which is executed at a time when carbon consumption is low.

[0229] Similarly, a spatial or temporal offset may be introduced in the processing of a request.

[0230] Another example is the system's behavior during periods of inactivity. Indeed, a cold start takes time, whereas a system that operates continuously, even when not under load, will consume a lot of power. Here again, a compromise must be found.

[0231] In other words, such a technique for measuring friction between the pillars of a software architecture has been presented.

[0232] It has been presented how to measure and evaluate the impacts of an architectural decision based on the objective of eco-design can have on other attributes, here called pillars of architecture.

[0233] A software or software system architecture is complex, encompassing data management, network communications, and even simple processing. Therefore, there are numerous attributes and properties to evaluate in order to understand, measure, and qualify an architecture in relation to the requirements.

[0234] The Pillars, or predominant attributes, usually considered are those presented previously, namely security, resilience, performance, cost, operational excellence and sustainability.

[0235] All these pillars are not independent and the optimization of one can affect the others (positively or negatively)

[0236] Other specific examples are now described.

[0237] The described technique is based on architectural decisions, usually recorded for example in ADRs and not on the blocks or components of the architecture even though the choice of such a component or block can be considered a decision.

[0238] A very simple and telling example of a decision and its impact on other pillars is data encryption.

[0239] Encrypting data is costly in terms of processing and mathematical operations, therefore it is not “frugal”. Removing encryption will thus have a sustainable effect on energy savings, but at the same time will compromise security

[0240] In this specific case, it is therefore indeed a “decision”

[0241] Let us take, however, another example, that of the choice of database.

[0242] Let us imagine the choice of a database having recognized frugality properties but which requires a license, there will then be an impact on the cost.

[0243] So it is the component itself that has an impact, but what we are considering here, more than the component, is the fact of having chosen it, the decision.

[0244] Decisions may concern a single block, for example on this database it is decided not to record access logs, which will make this block more virtuous (eco-responsible decision) but also reduce the possibilities of auditing (security pillar)

[0245] Decisions can also apply to the overall software architecture style chosen (microservices, serverless, etc.) or to the infrastructure level itself, i.e., the physical architecture, such as using low-power processors, which limits consumption and is therefore eco-responsible but can also result in a decrease in performance, or active / passive redundancy with two different data centers.

[0246] All the impacts of all decisions are cumulative, either at the block level or at the software architecture level. It is therefore possible to perform this summation at the level of a single block, a group of blocks, or even the overall architecture.

[0247] Let us take the case of a block B;, i being an index in the global architecture.

[0248] Each decision is noted DLJ, which represents decision j concerning block B;

[0249] The friction F for the pillar p will be denoted FP and is calculated as follows:

[0250] F d._

[0251] Unlike consumption measurement where measurements are added together, here, since the impacts can very well be positive, it is important to give values ​​not in N but in Ç.

[0252] For each decision dj (the component index is omitted here for simplicity) we have a factor pj such that it can be described: 102531

[0254] In this example, it is assumed that a given pillar can have a qualitative impact among 5 values: none (0), low (25), moderate (50), strong (75) and very strong (100).

[0255] Since these values ​​are all positive, a multiplicative factor is added which can take the values ​​-1 or 1 depending on whether the impact is positive (-1) or negative (1).

[0256] For example, removing a redundant data center drastically reduces costs (very strong impact) but at the same time reduces resilience.

[0257] The technique also takes into account the fact that not all decisions are equal and that some will have more, or less, impact than others depending in particular on the context or use case

[0258] In this respect, Wj weightings are added according to the equation: 102591 Fp^WjPjd.

[0260] In the example described, these weightings are given in terms of importance with three levels: low (corresponding to an importance weighting of 1), moderate (corresponding to an importance weighting of 1) and high (corresponding to an importance weighting of 2).

[0261] Therefore, if for example we had two decisions which for pillar p correspond to 50 but the first one, in the use case is more important, we will assign it an importance weighting of 2 and the other an importance weighting of 1, which would give weights of 0.66 (¾) and 0.34 (½).

[0262] It should be noted that a total sum must not exceed 100 when assigning these weightings.

[0263] If we then consider the system as a whole, the sum over the blocks is performed by adding for each block B; a weight of importance in the global system which we denote b; : 102641

[0265] And then the measurement of the system itself is added, that is to say the decisions taken at the system level and not at the block level, which is expressed by adding indices related to blocks and systems: 102661 FP = b^WjPjd j +^dst J—Ay JJ f 1

[0267] The process therefore makes it possible to find a compromise between efficiency and other performance indicators.

[0268] This compromise makes it possible to improve the efficiency of the software architecture 40 by controlling its impact on other expected performance indicators.

[0269] In some cases, blocks 44 and 46, for which a compromise must be managed between efficiency and a performance indicator, are known.

[0270] It is then advantageous to implement the aggregations of the estimation step E86 only for blocks 44 and 46 involved in the compromise.

[0271] Such a process is easy to implement.

[0272] The method is feasible by means of a performance estimation system 90, the estimation system 90 comprising a receiving module 92 implementing the receiving step E80, a storage module 94 storing the two bases of data, a retrieval module 94 implementing the retrieval step E82, a determination module 96 implementing the determination step and an estimation module 98 specific to implementing the estimation step E84.

[0273] According to another embodiment, the determination step E84 is carried out by interaction of the estimation system 90 with an application programming interface. In such a case, the storage module 94 stores only the first database.

[0274] In the example of [Fig.7], the estimation system 90 includes an information processing unit formed for example of a memory and a processor associated with the memory.

[0275] According to this example, the receiving module 92, the obtaining module 94, the determining module 96, and the estimating module 98 are each implemented as a software program, or a software component, executable by the processor. The memory of the estimating system 90 is then capable of storing a receiving software program, a obtaining software program, a determining software program, and an estimating software program. The processor is then capable of executing each of the following software programs: the receiving software program, the obtaining software program, the determining software program, and the estimating software program.

[0276] In an alternative not shown, the receiving module 92, the obtaining module 94, the determining module 96 and the estimating module 98 are each made in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array), or an integrated circuit, such as an ASIC (Application Specified Integrated Circuit).

[0277] When the estimation system 90 is implemented in the form of one or more software programs, i.e., in the form of a computer program, also called a computer program product, it is further capable of being stored on a computer-readable medium, not shown. A computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. By way of example, a readable medium is an optical disc, a magneto-optical disc, ROM, RAM, any type of non-volatile memory (e.g., FLASH or NVRAM), or a magnetic card. A computer program comprising software instructions is then stored on the readable medium.

Claims

Demands

1. A method for estimating the performance of a software architecture (40) formed by a set (42) of blocks (44, 46), the set (42) of blocks (44, 46) comprising at least one hardware block (44) and at least one software block (46), the estimation method being implemented by an estimation system (90), the estimation method comprising: - a step of receiving a set (42) of blocks (44, 46) forming a software architecture (40), - for each of the blocks (44, 46), a step of obtaining the elementary efficiency of the block (44, 46) by reading a first database, the first database associating with each block likely to be part of a software architecture (40) an elementary efficiency, - for each of the blocks (44, 46), a step of determining at least one elementary performance indicator, the at least one elementary performance indicator being distinct from efficiency,The determination step is implemented by reading from a second database, the second database associating with each block likely to be part of a software architecture said at least one elementary performance indicator, and - a step of estimating the performance of the software architecture (40) from the elementary efficiencies obtained and the elementary performance indicators.

2. Estimation method according to claim 1, wherein the second database is a decision table.

3. Estimation method according to claim 1 or 2, wherein the determination step is carried out by interaction of the estimation system (90) with an application programming interface.

4. Estimation method according to any one of claims 1 to 3, wherein the at least one performance indicator is chosen from the list consisting of a safety indicator, a reliability indicator and a quality indicator.

5. Estimation method according to any one of claims 1 to 4, wherein the performance indicators determined at the determination stage are a safety indicator, a reliability indicator, a performance indicator and a quality indicator.

6. Estimation method according to any one of claims 1 to 5, wherein the estimation step includes an aggregation of the elementary efficiencies to obtain an overall efficiency.

7. Estimation method according to claim 6, wherein each aggregation is implemented for only a part of the blocks (44, 46) of the set (42) of blocks (44, 46).

8. Method for realizing a software architecture (40) formed by a set (42) of blocks (44, 46), the set (42) of blocks (44, 46) comprising at least one hardware block (44) and at least one software block (46), the method comprising: - a step of implementing the estimation method according to any one of claims 1 to 7 on a set of candidate software architectures (40), to obtain the efficiency of each candidate software architecture (40), - a step of selecting the candidate software architecture (40) exhibiting the highest performance, and - a step of realizing the selected software architecture (40).

9. A system (90) for estimating the performance of a software architecture (40) formed by a set (42) of blocks (44, 46), the set (42) of blocks (44, 46) comprising at least one hardware block (44) and at least one software block (46), the estimation system (90) comprising: - a receiving module (92), the receiving module (92) being adapted to receive a set (42) of blocks (44, 46) forming a software architecture (40), - a storage module, the storage module being adapted to store a first database associating with each block likely to be part of a software architecture an elementary efficiency, - a retrieval module (94), the retrieval module (94) being adapted to, for each of the blocks, obtain the elementary efficiency of the block (44, 46) by reading the first database, - a determination module (96), the determination module (96) being specific to, for each of the blocks (44, 46),determine at least one elementary performance indicator, the at least one elementary performance indicator being distinct from efficiency, the module determining the at least one elementary performance indicator, by reading from a second database, the second database associating with each block likely to be part of a software architecture said block at least one basic performance indicator, and - an estimation module (98), the estimation module (98) being suitable for estimating the performance of the software architecture (40) from the elementary efficiencies obtained and the elementary performance indicators.

Images