Code generation for classical-quantum software systems modeled in UML

Class diagrams offer a comprehensive static view of the system, illustrating how classes and packages are structured. The class diagram of the running example can be seen in Fig. 3. The <  < quantum >  > stereotype can be used with both whole packages and individual classes to indicate components that support functionality and allow them to be developed as quantum circuits, algorithms, or similar artifacts.

Bild vergrößern

The <  < Quantum Driver >  > stereotype is used to define class drivers that manage invocations to the quantum software components. These drivers are responsible for initiating quantum operations and ensuring proper communication between classical and quantum parts of the system. In the example of Fig. 3, the class ‘EuropeanCallDriver’ plays this role.

The <  < Quantum Request >  > stereotype is designed to model quantum calls or requests from the <  < Quantum Driver >  > class in the hybrid software packages (the ‘classicalquantumlogic’ package in the example) to other <  < quantum >  > classes. The <  < Quantum Request >  > stereotype can be used with an association class between the <  < Quantum Driver >  > class and the <  < Quantum >  > class (see the ‘EuropeanCallQuantumRequest’ class in Fig. 3). This provides a detailed view of the interactions (e.g., the kind of quantum hardware where the algorithm will be executed, number of shots, and other parameters).

Activity diagram models the dynamics (algorithms or quantum circuits) of specific quantum software components. The definition of the activity diagram of the running example can be seen in Fig. 4. Quantum algorithms are encapsulated within a single compound activity decorated with the <  < quantum circuit >  > stereotype. This activity serves as the container for the entire circuit, promoting reusability across different circuits, a common practice in quantum programming. Within the parent activity, various activity partitions (depicted as horizontal swim lanes) can be delineated using the <  < qubit >  > stereotype, corresponding to the number of qubits employed in the algorithm. Each quantum gate applied within the circuit is represented as an action element and is positioned within its respective swim lane, corresponding to the qubit upon which the gate operates or is controlled. Ordinary quantum gates, such as H, Y, and Z are denoted as call operation actions supplemented with the <  < quantum gate >  > stereotype. Conversely, controlled gates are modeled as multiple action elements. Control qubits are represented by send signal action elements decorated with the <  < controlled qubit >  > stereotype, while the applied gate is depicted by the counterpart element, accept event action, supplemented with the <  < quantum gate >  > stereotype (see Fig. 4). Furthermore, to impart semantic clarity regarding the relationships between control qubits, various UML constraint elements are established among the involved action elements. In addition to these core elements, specialized operations, such as qubit measurement, are symbolized by value specification action elements accompanied by the respective stereotype <  < measure >  > .

Bild vergrößern

In our example (see Fig. 4) the flow of quantum gates is modeled in an explicit way. Thus, control flow elements connect quantum gates (or its controlled counterpart) to define the order of application as suggested in the source code. Of course, activity diagrams can abstract this flow through the usage of fork and join elements (similarly to the standard notation). Sometimes, the exact order of gates’ application is decided later, when the circuit is executed, and it depends, for example, on the hardware topology. However, an exact definition of the order of quantum gates could be useful in some scenarios for considering concerns regarding transpilation, optimization, among others.

It should be noticed that the proposed approach focuses on the code generation of circuits that are fully defined in activity diagrams with simple activity elements. This means that specific modeling abstractions for circuits that follows some design pattern, or are based on some algorithm’s families (e.g., Quantum Fourier Transform (QFT) or Variational Quantum Eigensolver (VQE)) are out of the scope of this proposal. Those special algorithms have some repeated structured which, for larger problem definitions, could result in extremely huge circuits. To prevent this, UML provides structured activity elements (for sequencing, conditionals, loops, and expansion regions) that allows represent compound/repeated structures in an abstract way. However, those elements are outside of the scope of the current proposal for code generation.

The quantum UML profile proposes the use of activity diagrams to represent quantum circuits in a similar way to the existing notations. In the context of quantum circuits’ modeling in isolation, this notation does not provide any advantage over traditional notation. However, the main benefits of UML activity diagrams lay in the context of modeling hybrid software systems, which are the followings:

As explained previously, companies that could benefit from quantum computing will eventually have to evolve their information systems toward hybrid software. This evolution must imply, at some, the designing of the hybrid information system, which could be used to generate the source code of the hybrid information system. For this reason, the rationale of the study is to prove the proposed technique with which to generate both classical (Python) and Quantum (Qiskit) code in combination (Classical-Quantum code) is effective and efficient.

The research objectives of this case study are to determine whether it is possible (i) to generate the same information in classical, quantum and hybrid code as their representation in high-level UML designs, (ii) to obtain equivalent execution results in the quantum with regards to the results of the same program generated with other existing tools (IBM Quantum Circuit composer), and (iii) to generate the target hybrid software in an efficient way regarding the size of the design.

In the presented study three main research questions have been stablished, one for each specific objective. Firstly, RQ1 is related to the completeness of the output hybrid code with respect to the input hybrid systems representation. Secondly, RQ2 focuses on assessing whether the results from the execution of the generated quantum code are consistent with respect to the execution of the quantum circuit of which the UML model has been inspired to. Finally, RQ3 analyzes whether the forward engineering technique (for both classical and quantum code generation) is efficient and scalable, specifically assessing how the generation time increases as the size of the input hybrid software models grows.

It should be noticed that the research questions have been intentionally defined as open questions (starting with ‘how’) rather than define dichotomic, closed questions. This design allows to analyze the results in a more qualitative way apart from the expected quantitative analysis.

Table 1 provides a summary of the variables selected for empirically validate the study. For each variable is indicated: (i) the concept to be measured, (ii) the research question intended to answer, (iii) the name of the variable, (iv) a short definition (or formula) of the variable, (v) the scale type, and (vi) the range definition for all the possible values.

First, RQ1 focuses on the effectiveness of the proposed technique. To do this, it has been followed two alternative approaches, an information retrieval approach by considering precision, recall and F-measure [56], and a machine translation approach by using the CodeBLEU metric [57].

The information retrieval approach evaluates the accuracy of the generated code elements compared to the expected elements derived from the UML models. To establish the ground truth, we manually analyzed the UML models and determined the expected output code. Precision measures the proportion of relevant elements correctly generated, recall assesses the proportion of relevant elements that were retrieved, and F-measure provides a harmonic mean of precision and recall giving an overall effectiveness score.

For example, consider a UML class diagram containing methods for initializing qubits and applying quantum gates. The manually judged ground truth for this model includes the corresponding Python code with Qiskit, defining a class with the same methods that correctly perform the initialization and gate operations. This manual ground truth serves as the benchmark to assess the accuracy and completeness of the automatically generated code. Precision, recall, and F-measure are calculated by comparing the elements in the generated code to those expected, in our viewpoint, according to the specified elements in the UML model.

To compute precision and recall, it considers elements in the target code that should be generated from the most meaningful and representative elements in both kind of UML diagrams. Regarding class diagrams, it considers the number of packages, classes, and class operations and attributes. Regarding the activity diagrams, it considers the number of activity partitions (qubits), actions (quantum gates) and data store node elements (measures). Due to both kind of elements present in class and activity diagrams, the study can distinguish between global precision and recall metrics for the hybrid (Python) code, and those only for quantum (Qiskit) code.

This approach leverages well-established metrics from the information retrieval domain to quantify the effectiveness of our code generation approach. These metrics provide a robust framework for evaluating how well our generated code aligns with the expected outcomes, particularly in terms of relevance and completeness.

Alternatively, a machine translation approach has been also followed to answer RQ1 by considering CodeBLEU metric [57]. The proposed code generation technique is deterministic. This means that given a specific UML model, the algorithm will always produce the same version of the code. This ensures consistency and reproducibility of the results. Therefore, no different versions of the code can be generated from the same UML model.

Additionally, to provide further insights, RQ1 includes the number of compilation errors as a valuable metric to assess the effectiveness of the code generation process. Given that the code generation technique provides a draft or skeleton of the software system, some compilation errors are to be expected, especially related to elements that require further refinement or integration. This metric is included to be analyzed qualitatively, helping to identify the types of errors (e.g., missing dependencies, type mismatches) that arise in the generated code, and providing guidance for possible solutions or improvements. Although the expected result for generation tools is that the whole generated code compiles, it is important to note that many of these compilation errors can be easily addressed with automatic, predefined actions in a target tool that integrates this transformation. For example, common fixes could include automatically adding missing dependencies, adjusting data types to ensure compatibility, or marking sections of code that require further modifications. These predefined solutions would ensure that the generated code can quickly become compilable and functional, while leaving space for customization based on the specific needs of the user.

Regarding RQ2, the study attempts to assess the functional correctness of the code generated through the proposed technique. This question only focuses on the quantum code and attempts to determine if the execution result of the generated code is correct with respect to the expected one. To achieve this, the benchmark used is the code generated for the same circuit modeled in IBM Quantum Composer, which is able to generate Qiskit code. Thus, both circuits (the one generated by this proposal, and the one generated with IBM Quantum composer) are executed in the same quantum computer simulator (ibm_qasm simulator). Then, the set of frequencies obtained for each possible combination are compared. The distance between the distributions of frequencies is computed by means of Kullback–Leibler (KL) divergence. It is important to note that the simulator in question introduces a certain level of noise to achieve more realistic results. However, to mitigate the impact of this simulated noise, the same seed is used for all scenarios within each simulation. As a result, despite the presence of noise, the outcomes remain consistent across all cases within a simulation. This consistency allows for meaningful comparisons between hypothetically equivalent circuits.

Finally, to assess RQ3 and to determine if the technique would be efficient, and suggest if it is scalable for larger models, it focuses on analyzing the correlation between the size of the input model and the time spent on code generation.

The generation time is divided into the time spent for loading the input UML model and the time necessary to execute all the EGL rules defined. Also, both time metrics are computed for class and activity diagrams in isolation.

To evaluate the code generation from classical-quantum software systems designs, firstly it is necessary to define the criteria for selecting the classical-quantum software systems which are going to be modeled. These systems have been manually modeled as there are not open classical-quantum software systems designs available in the literature. However, these designs have been based on existing applications proposed in the literature. Table 2 shows the criteria chosen to select those cases.

Criterion C1 has been stablished because of the huge number of proposals concerning the use of quantum computing in the different fields of science (i.e., the use of quantum computing in machine learning). However, some proposals might not provide enough context for modeling complex hybrid systems. This is what C2 is defined. Criterion C2 has been chosen because, although certain companies have made announcements that quantum computing will be used to solve certain problems, these announcements do not provide any information other than the objective of what it is intended. In the absence of information on the quantum algorithm or even what type of quantum computing paradigm will be employed, the modeling of these systems would be inaccurate. Criterion C3 has been selected since this work considers the generation of classical-quantum code is achieved from hybrid system designs, where the quantum code generation is performed from UML activity diagrams representing quantum circuits, which employs a gate-based approach. This is due to the scope of the proposed technique. Criterion C4 has been defined in order to model hybrid systems that attempt to support real quantum applications. The fact that there are no hybrid system designs available yet difficult the evaluation of the technique, that is why this criterion was established. By the application of this same criterion, most of the cases come from proposals by designed by the industry, since QUTAC is a consortium of leading German companies (BMW-Group, Bosch, and Siemens, among others) that have the objective of bringing quantum computing to the level of practical application.

After applying the criteria previously defined, 7 cases have been selected and modeled using the Q-UML profile. Table 3 shows the cases under study, showing: (i) the identifier of the case, (ii) the company/companies that proposed that case, (iii) the business challenge desired to be solved, and (iv) the algorithm employed. The designed systems are available in [55].

The study protocol defines how the selected cases has been analyzed and how the derived data have been collected and eventually analyzed.

Figure 11 depicts the case study protocol followed. This protocol consists in three main phases with various steps within them. The first phase (topside of Fig. 11) compromises the designing of the input hybrid system. As mentioned previously, in the literature there are not UML designs for hybrid software systems, so in order to validate the technique, we manually modeled the UML designs based on proposals of the industry and available quantum algorithms. The steps within this phase are: (i) researching for possible hybrid software systems based on the criteria stablished in Table 2; (ii) based on the candidate hybrid software system, it was time to the researching of the possible quantum algorithms that would attempt to solve the problem for what is designed the hybrid system; once the candidate case has been selected, as well as its quantum algorithm it was time to the (iii) modeling the class diagram and (iv) the activity diagram using the open source Model-Based Engineering tool, Papyrus [59]. This phase generates the following outputs:

Bild vergrößern

The second phase of the case study protocol (middle-side of Fig. 11) concerns the generation of the code from the hybrid system software designs made on the previous phase. This steps within this phase consists of: (i) adding the models from the previous phase to an automatic test environment; and, afterward, it is carried out (ii) the execution of the model-to-Python code generator (using as input the class diagram), and (iii) the execution of the activity-to-Qiskit code generator (using as input the activity diagram). The outputs of this second phase are:

In the last phase of the case study protocol (bottom side of Fig. 11) it is addressed the calculation of the metrics and its integration on a dataset. The tasks of this phase are: (i) the calculation of the metrics from the generated Python code, (ii) the calculation of the metrics of the Qiskit code generated, (iii) the recollection of the execution times of the model-to-Python and model-to-Qiskit for its later (iv) integration in the dataset. The output of this last phase is the dataset of the case study available in [55], as well as the transformation generators (both the Python and Qiskit) and the metrics calculator.

To complete the whole dataset, the application of the tool has been done on a laptop with an i7 10510U with 2.30 GHz, 16 GB of RAM and running on an SSD with Windows 11 × 64 bits. Table 4 shows the whole dataset completed after executing the model-to-text transformations in the 7 manually modeled cases. The first rows provide information about the input UML diagrams (both class and activity diagrams). Then, the metrics obtained for the generation of Python code and Qiskit, respectively. For each group of metrics, it is depicted to what research question the metric belong to (according to Sect. 6.1.3).

The data analysis made for answering the stablished research questions concerns both a quantitative and qualitative analysis. Regarding the quantitative analysis, the following methods have been employed:

Together with each of the methods of analysis (i.e., for all research questions) a qualitative study of the data obtained has been done. This type of analysis aims toward an analytical generalization, focusing instead on understanding the nature of the research problem rather than the quantity of observed characteristics [60].

Regarding hybrid code generation, Fig. 12 shows a good effectiveness of the technique from the perspective of a retrieval information problem. The values indicate an average of 99,2% in the case of precision, 89,7% for recall, and 94,2% for F-Measure. Of all the cases, C2 case has the worst results (even though all its metrics are above 80%). This is due to the impossibility of transforming certain data types of some attributes into classical-quantum code. The objective of this case is to design a classical-quantum system that solves partial differential equations using the HHL algorithm. For this purpose, the use of vectors is used, for example, to indicate the probability distributions or the variables to be minimized. The transformation of vectors into hybrid code has not been considered in this technique, so that all attributes with a vector data type are represented as ‘Undefined’. This non-transformation and lack of datatype specification implies that the values of the precision, recall and, consequently, F-Measure decreased.

Bild vergrößern

Moving on to the analysis of the effectiveness of the quantum code generation, to perform the calculation of the different metrics, Fig. 13 shows the results of the quantum code generation. As in the hybrid code generation, the results are promising, where most of the values are close to 100% for precision, recall and F-Measure metrics. Of all the cases, the C3 case stands out, which has a precision of 66,7%. In this case it is intended to use imaging techniques to identify structures and distribution of molecules in tissues. To compare the images from the structures of molecules images, in this case it is proposed the swap test [61], since it is a widely used protocol for calculating the overlap between two quantum states [62‐64]. The input activity diagram is shown in Fig. 14 (A), while the inspired quantum circuit is in Fig. 14 (B). The respective quantum code generated from the activity diagram is Fig. 14 (C). One of the problems of this program lies in the CSWAP gate, which needs three qubits as parameters: one indicating the control and the other two on which the swap is to be performed. However, it can be noticed that the generated CSWAP gate is missing one of the parameter qubits (see line 17 in the right-hand side of Fig. 14). In addition, unnecessary elements are generated for this circuit, such as the imports of the numpy library and the ClassicalRegister function of the Qiskit library.

Bild vergrößern

Bild vergrößern

It should be noted that code generation, especially in complex domains, often involves iterative improvements to account for all possible scenarios and variants. Modifications aimed at eliminating irrelevant elements could, in some cases, result in lower precision, as other relevant elements might no longer be retrieved. Therefore, our approach aligns with common practice in the code generation field, striving to automate as much of the process as possible by providing a skeleton or draft of the code, while acknowledging the necessity of human intervention to refine and finalize the output. This practice is standard except for some advanced low-code tools designed for specific applications, which can generate more complete and ready-to-use code.

With respect to the CodeBLEU score of the generated quantum code, Fig. 15 shows the CodeBLEU results disaggregated together with the CodeBLEU score. While it is true that the results are relatively low for the values of \(BLEU\) and \({BLEU}_{weight}\) (the CodeBLEU score can be up to 1) reasonably good values are obtained for the measures of \({Match}_{ast}\) and \({Match}_{df}\).

Bild vergrößern

The two first metrics are lower than others. However, the \(BLEU\) metric from the CodeBLEU equation was designed to measure how well a candidate translation matches a set of translation references. As [57] stated, “BLEU is not suitable for the evaluation of code synthesis without considering the characteristics of the programming language.” So, this value would be almost every time is used, low. Therefore, although it is part of the equation for calculating the CodeBLEU score, focusing on the BLEU score is not appropriate.

The \({BLEU}_{weight}\) was introduced because, unlike natural languages, programming languages are manually designed and have only a few keywords such as “int”, “public” and so on. This measure introduces the weighted n-gram match to assign different weights for different n-grams, so that the keywords may have higher weights. However, the code generated has almost no reserved words from the Python language, while from Qiskit it does, which does not apply to contribute weights to the n-gram match.

The \({Match}_{ast}\) metric calculates the accuracy of the Abstract Syntax Tree (AST) of the reference code and the candidate. While it is true that the values are high, they could be more so with a few simple changes that would not affect the functionality of the program, but that would substantially modify the result of the CodeBLEU. Figure 16 shows a comparison of the original quantum code generated by the IBM Quantum Circuit composer when implementing the C3 circuit, and the one generated by the technique from the UML model.

Bild vergrößern

While the code generated from the IBM Quantum Circuit composer is a monolithic program, the code generated with the technique contains the circuit in a single method. Another difference is that the code generated by the technique generates one quantum register per qubit. However, in the code generated by IBM, a single quantum register is declared with the same size as the number of qubits in the circuit. This implies that, in order to indicate on which qubit a quantum gate is going to perform an operation, the index of the qubit in the quantum register is indicated. The latter is what most affects the metric, however it is a design decision used in this proposal. Figure 17 shows a comparison between the \({Match}_{ast}\) measurements obtained from the generated Qiskit code and for the code generated from UML models that was then manually modified to use a single quantum register instead of a single quantum register per qubit. Only with that change, \({Match}_{ast}\) values are close to 1; this being a variation that does not affect the functionality of the program to any extent. This makes us suppose that the syntax of the generated code with respect to the code of the original circuits is similar in spite of the results of the CodeBLEU value obtained (see Table 4).

Bild vergrößern

Finally, moving on to the last metric for analyzing the completeness of the code generation, it has been studied the number of compilation errors within each case. As it can be seen in Table 4, the generated code (both Python and Qiskit) are not exempted of compilation errors. In the dataset available at [55], all the compilation errors for each case are gathered. These compilation errors mainly appear because of two reasons: (i) hyphens in the project’s name, and (ii) ‘Undefined’ type.

At the time of manually developing the class diagrams, most of the cases had a clue name for identifying them, where it consisted of the name of the company and the purpose of the system, joined by hyphens (for example, the clue name of C1 was ‘AIRBUS-WINGBOX’, as it was proposed by the company Airbus and its system has the purpose of optimizing the wing-boxes of the aircrafts). These symbols are fully allowed in UML models. When transforming such class diagrams, it was not considered the fact that the associations modeled in the diagram are transformed into importations of the classes using the full route to such class. The compilation units raise because the importation instruction cannot contain hyphens in the route of the class, so for each association of the case which prototype’s name contains a hyphen, there is a compilation error. Of course, this kind of error is easy to manage and fix. For example, a model validation could be performed on the UML model to detect, and mange issues derived from naming conventions problems. These kinds of techniques should be provided according to the desired target programming language and certain conventions. Hence, this is outside of the scope of this current research.

The second reason of this compilation errors concerns the scope of the EGL Transformation. As mentioned previously, it was not considered the transformation of certain elements, like the array datatype. So, for these attributes bound to these datatypes, the transformation generates attributes with the type ‘Undefined’, which is not a reserved word of Python. So, for each attribute with this undefined type, a compilation error raises. As a design decision, the transformation use this word for the complex data types, which can be then manually completed as other part of the code structure provided.

For proving these, it can be seen the C6 is the one with the lowest number of compilation errors (see Table 4). This case is the same as the one presented in Sect. 5. This case does not contain any hyphens on the name and all the variables are defined with its corresponding type. So, the transformation does not generate any compilation errors.

In summary, based on the results obtained, it can be concluded that the completeness of both hybrid and quantum code is adequate. Firstly, from a retrieval information problem perspective, the precision, recall and F-Measure metrics indicate that the effectiveness of the technique is optimal. Then, from a machine translation viewpoint perspective, although the CodeBLEU score is quite low, the \({Match}_{ast}\) metric indicates remarkable similarities between the original quantum circuit and the generated Qiskit program through an AST comparison. Finally, even if the Python code generation is not free of compilation errors, most of them are reasonable and affordable with relatively low effort.

As mentioned above, to evaluate the correctness of the generated code, the distances of the frequencies of the results from the execution of the original quantum circuit and the generated quantum code have been measured using the Kullback–Leibler divergence metric. When executing a quantum program, the result is a vector of the possible values represented with the measured qubits and the number of times (frequency) that such possible value has occurred.

Table 4 shows the results of the distances between the results of the execution of times of the original quantum circuit and the generated quantum code one, where the values do not exceed 0.1. This means the quantum generated code provide equivalent results to those generated with IBM Quantum Composer.

To visualize these results graphically, Fig. 18 shows the specific results for the case C6 regarding the frequency distribution of the possible values of the qubits of the circuit generated with IBM Quantum Composer (gray bubbles) and of the generated code (blue bubble). The size of the bubbles indicates the frequency of the qubit values. As can be seen, both the size of the bubbles of the qubit values and the frequencies of the results are very similar between the original and the generated circuit, so the very low value of Kullback–Leibler divergence for this same case (0.0) makes sense.

Bild vergrößern

It can be concluded that, based on the distances of frequencies, RQ2 can be positively answered, as the functional correctness of the technique is ensured.

In order to evaluate the performance of the tool with larger models, first it is necessary to discover which of the variables related to the size (acting as the independent variable) affect the code generation time in a greater extent. Figure 19 shows the matrixes containing the Pearson correlations for each pair of size and timing variables.

Bild vergrößern

Regarding the values obtained from the hybrid code generation (see the left-hand side of Fig. 19) it can be observed that the rule execution time has a certain correlation regarding the size of the input UML model (0.66). However, model loading time is not affected by any other parameter, so it could consider as constant time necessary to prepare the EGL engine before code generation. As a result, the overall generation time is not highly correlated with the size of the input UML models (0.57). Referring to the time data obtained in the quantum code generation (see the right-hand side of Fig. 19), it can be noticed that, as in the hybrid code generation, the model loading time has no relationship with any other parameter. However, the execution of the transformation rules does have a strong correlation with both the size of the activity diagram and the lines of code the generated quantum code. The overall correlation for quantum code generation (0.7) is higher than correlation for hybrid code generation.

Despite the small number of cases available, the results indicate that the generation time increases linearly, rather than exponentially. Although this was the hypothesized expectation, it suggests the scalability of the technique for larger UML models with a larger number of elements. It is important to note that, while the models used in this study may not be extremely large, the goal was to evaluate how the generation time scales with model size. This analysis is intended to extrapolate the results to larger models, where we anticipate similar linear growth in generation time.

Regarding the definition of constructs, this study considers three main measurable concepts. First, the completeness for the generated code, whose assessment is based on information retrieval metrics (precision, recall and f-measure). Those measures offer a comprehensive and balanced evaluation framework for code generation techniques, enabling researchers and practitioners to assess the completeness of the generated code relative to the desired specifications or requirements. Unfortunately, precision and recall do not consider the context and semantics of the code.

To mitigate the previous threat, the study considers the CodeBLEU metric from the translation machine field. This metric provides a more flexible and tolerant evaluation criterion, accommodating variations in coding styles and conventions. The threat of CodeBLEU is that is extremely sensitive to coding style and conventions. As it can be seen in Sect. 6.2.2, just changing one variable type and how it is called, the metrics grows exponentially.

In order to limit that threat, the functional correctness construct was also included in the study, at least for the quantum code. The assessment of this construct is based on the execution results comparison of the generated code and the one generated with IBM quantum composer. The outgoing statistical distributions are then compared. Although it ensures an approximate functional correctness, it possess some measurement bias. For example, the usage of the IBM quantum composer as the alternative generation tool when there are others. Also, the interpretability of results could be different if the quantum circuits manually modeled differ. Despite the threats, we believe it can be used to get an orientation about the functional correctness.

Finally, assessing scalability in this study presents significant challenges due to the limited availability of larger quantum systems and the inherent complexity in simulating and validating results for systems beyond a few qubits.

It refers to the generalizability of results. In this regard, the obtained results can strictly be generalized for UML designs of hybrid software systems based on the UML profile used in this proposal. Despite that, since UML is a standard, similar quantum extensions could be considered as modeling languages in which results could be potentially generalized.

Regarding the output, the proposal is only focused on Python/Qiskit code. Hence, results can only be generalized for this programming language. Although it should be noted that Python is by far the most widely used language in quantum computing [65].

Moreover, due to the MDE principles followed in this proposal, it should be easy to extend the proposal to generate code in other programming languages.

In any case, the mitigation action for those threats should be, in the future, conduct further case studies involving other modeling languages and different programming languages.

There are no significant data reliability concerns. The only threat could be the subjective judgment of researchers for tagging irrelevant and missing elements in the generated code, which is used to compute precision and recall. In order to ensure reliability and future replications, the whole dataset is freely available so that other researchers can check the data collection and the judgments made by researchers regarding that metrics [55].

Changes in the external environment or technology landscape is quite possible due to the current changing rate in quantum computing and quantum software technology and practices. Because of this, there is a certain contextual threat that may limit the relevance or applicability of findings from in future case studies. The accessible dataset provided is useful and will help to compare current with future results despite the possible changes that can occur.