# A Graph-Based Approach for Modelling Quantum Circuits
## 6 Evaluation of the Proposal
### Ease of Implementation of Model-to-Text Transformations  
When defining model-to-text transformations, the order of preference may change depending on the structure of the text to be generated, code in this case. It is impossible to consider all cases of text generation to provide some guidance but we will basically classify them according to two attributes: whether they need to respect the overall structure of the quantum circuit (horizontal, vertical, unimportant) and whether multi-qubit gates play some special role or need to be considered separately.  
The \"slice\" strategy reflects the vertical order of the circuit, while the \"swim-lane\" strategy reflects the horizontal order. The \"mixed swim-lane\" strategy is in the middle of both (but favours the horizontal structure), and strategies \"mixed linear\" and \"linear\" reflect neither. If multi-qubit gates play a special role or need to be considered separately, the strategies \"mixed swim-lane\", \"mixed linear\" and \"slice\" are better than \"swim-lane\" and \"linear\", because multi-qubit gates are easy to identify in the former (although you can always look for Control gates in the model to find them).  
Specifically, when considering code generation, it all depends on the target quantum language chosen. For languages that follow the imperative and structured paradigm, such as IBM's Qiskit [35], developed as a Python library, we think that the best strategies are \"slice\", \"mixed linear\" and \"linear\", because for this task the vertical structure is more important than the horizontal one. Then come the other two strategies, since in them the transformation needs to identify and consider the dependencies between nodes in a multi-qubit gate.  
In summary, from best to worst, the preferred strategies for specifying model-to-code transformations are: \"slice\", \"mixed linear\", \"linear\", \"mixed swim-lane\", \"swim-lane\".  
Again, this order is not affected by the transformation that reduces the number of modelling elements, but rather it makes code generation easier. This is because it eliminates the need to navigate Edges, which are no longer needed because model-to-text transformations are usually the last to be performed in a model-driven development framework.  
Table 3 presents a summary of the three characteristics analysed in this section. The classification is by no means an absolute one. Each user must choose the most appropriate strategy for their use case. There is no single best strategy for all scenarios.  
This classification reinforces the idea presented in Section 5.2 of having a set of model transformations between the different strategies that have been presented in this article. In this way, each phase of an MDE development process could be addressed using the most appropriate strategy for the task at hand.  
It should also be possible to generate code-to-model transformations that extract the quantum circuit implementation from the input source code. In this case, the \"linear\" strategy is the most appropriate one because it assumes that there is no horizontal or  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Strategy** & **CM** & **M2M** & **M2T** \\ \hline Slice & \(+1\) & \(+1\) & \(+2\) \\ Mixed swim-lane & \(+2\) & \(+2\) & \(-1\) \\ Swim-lane & \(-1\) & \(+1\) & \(-2\) \\ Linear & \(-2\) & \(-2\) & \(+1\) \\ Mixed linear & \(+2\) & \(-1\) & \(+2\) \\ \hline \hline \end{tabular}
\end{table}
Table 3: Summary of suitability of the strategies for performing operations related to modelling activities using a [\(-2\),\(2\)] Likert scale. CM stands for ‘changes in models’, M2M for ‘model-to-model transformation’ and M2T for ‘model-to-text transformation’.  
vertical ordering, and therefore the order in which the code is written will suffice for this task. Although we are still in the infancy of QC, it is possible that in the short term there will be modernisation needs that will be answered by the application of holistic approaches such as KDM [36].