<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1 20151215//EN" "http://jats.nlm.nih.gov/publishing/1.1/JATS-journalpublishing1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xml:lang="en" article-type="research-article" dtd-version="1.1">
<front>
<journal-meta>
<journal-id journal-id-type="pmc">CMC</journal-id>
<journal-id journal-id-type="nlm-ta">CMC</journal-id>
<journal-id journal-id-type="publisher-id">CMC</journal-id>
<journal-title-group>
<journal-title>Computers, Materials &#x0026; Continua</journal-title>
</journal-title-group>
<issn pub-type="epub">1546-2226</issn>
<issn pub-type="ppub">1546-2218</issn>
<publisher>
<publisher-name>Tech Science Press</publisher-name>
<publisher-loc>USA</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">66190</article-id>
<article-id pub-id-type="doi">10.32604/cmc.2025.066190</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Article</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>A Metamodeling Approach to Enforcing the No-Cloning Theorem in Quantum Software Engineering</article-title>
<alt-title alt-title-type="left-running-head">A Metamodeling Approach to Enforcing the No-Cloning Theorem in Quantum Software Engineering</alt-title>
<alt-title alt-title-type="right-running-head">A Metamodeling Approach to Enforcing the No-Cloning Theorem in Quantum Software Engineering</alt-title>
</title-group>
<contrib-group>
<contrib id="author-1" contrib-type="author" corresp="yes">
<name name-style="western"><surname>Kim</surname><given-names>Dae-Kyoo</given-names></name><email>kim2@oakland.edu</email></contrib>
<aff id="aff-1">
<institution>Department of Computer Science and Engineering, Oakland University</institution>, 115 Library Dr., <addr-line>Rochester</addr-line>, MI <addr-line>48309</addr-line>, <country>USA</country></aff>
</contrib-group>
<author-notes>
<corresp id="cor1"><label>&#x002A;</label>Corresponding Author: Dae-Kyoo Kim. Email: <email>kim2@oakland.edu</email></corresp>
</author-notes>
<pub-date date-type="collection" publication-format="electronic">
<year>2025</year>
</pub-date>
<pub-date date-type="pub" publication-format="electronic">
<day>03</day><month>07</month><year>2025</year>
</pub-date>
<volume>84</volume>
<issue>2</issue>
<fpage>2549</fpage>
<lpage>2572</lpage>
<history>
<date date-type="received">
<day>01</day>
<month>4</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>26</day>
<month>5</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2025 The Author.</copyright-statement>
<copyright-year>2025</copyright-year>
<copyright-holder>Published by Tech Science Press.</copyright-holder>
<license xlink:href="https://creativecommons.org/licenses/by/4.0/">
<license-p>This work is licensed under a <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</ext-link>, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="TSP_CMC_66190.pdf"></self-uri>
<abstract>
<p>Quantum software development utilizes quantum phenomena such as superposition and entanglement to address problems that are challenging for classical systems. However, it must also adhere to critical quantum constraints, notably the no-cloning theorem, which prohibits the exact duplication of unknown quantum states and has profound implications for cryptography, secure communication, and error correction. While existing quantum circuit representations implicitly honor such constraints, they lack formal mechanisms for early-stage verification in software design. Addressing this constraint at the design phase is essential to ensure the correctness and reliability of quantum software. This paper presents a formal metamodeling framework using UML-style notation and and Object Constraint Language (OCL) to systematically capture and enforce the no-cloning theorem within quantum software models. The proposed metamodel formalizes key quantum concepts&#x2014;such as entanglement and teleportation&#x2014;and encodes enforceable invariants that reflect core quantum mechanical laws. The framework&#x2019;s effectiveness is validated by analyzing two critical edge cases&#x2014;conditional copying with CNOT gates and quantum teleportation&#x2014;through instance model evaluations. These cases demonstrate that the metamodel can capture nuanced scenarios that are often mistaken as violations of the no-cloning theorem but are proven compliant under formal analysis. Thus, these serve as constructive validations that demonstrate the metamodel&#x2019;s expressiveness and correctness in representing operations that may appear to challenge the no-cloning theorem but, upon rigorous analysis, are shown to comply with it. The approach supports early detection of conceptual design errors, promoting correctness prior to implementation. The framework&#x2019;s extensibility is also demonstrated by modeling projective measurement, further reinforcing its applicability to broader quantum software engineering tasks. By integrating the rigor of metamodeling with fundamental quantum mechanical principles, this work provides a structured, model-driven approach that enables traditional software engineers to address quantum computing challenges. It offers practical insights into embedding quantum correctness at the modeling level and advances the development of reliable, error-resilient quantum software systems.</p>
</abstract>
<kwd-group kwd-group-type="author">
<kwd>Metamodeling</kwd>
<kwd>no-cloning theorem</kwd>
<kwd>quantum software</kwd>
<kwd>software engineering</kwd>
</kwd-group>
</article-meta>
</front>
<body>
<sec id="s1">
<label>1</label>
<title>Introduction</title>
<p>Quantum computing introduces a new approach to computation by using quantum mechanical phenomena to perform calculations that are difficult for classical computers. It relies on superposition, where quantum bits (qubits) can exist in multiple states simultaneously, and entanglement, which connects the states of multiple qubits such that no single qubit&#x2019;s state can be determined independently. These characteristics enable quantum computers to process information in parallel, enhancing the speed of certain computations. However, quantum mechanics also brings specific limitations, notably the no-cloning theorem [<xref ref-type="bibr" rid="ref-1">1</xref>], which prevents the exact duplication of an arbitrary unknown quantum state. This principle is essential to quantum information theory and affects quantum cryptography, error correction, and communication protocols.</p>
<p>While quantum software development is advancing, there remains a gap in software engineering methods for modeling and representing quantum mechanical principles like the no-cloning theorem. Metamodeling techniques, particularly those based on UML, have been effective in outlining domain concepts and relationships in emerging areas. These frameworks offer detailed abstractions and formal specifications that can adapt to include quantum mechanical principles. When extended, these methods provide a foundation for designing, analyzing, and validating quantum software systems, helping to bridge the gap between quantum mechanics and software engineering methodologies.</p>
<p>Several quantum software modeling approaches have been proposed (e.g., [<xref ref-type="bibr" rid="ref-2">2</xref>&#x2013;<xref ref-type="bibr" rid="ref-6">6</xref>]). These include graph-based modeling of unitary circuits, offering circuit-level abstractions for quantum computation using model-driven engineering [<xref ref-type="bibr" rid="ref-2">2</xref>]; a UML profile for designing hybrid classical-quantum systems through stereotypes and multiple diagram types [<xref ref-type="bibr" rid="ref-3">3</xref>]; the Talavera Manifesto, which outlines principles and commitments for establishing quantum software engineering as a discipline [<xref ref-type="bibr" rid="ref-4">4</xref>]; a lifecycle model for developing hybrid quantum applications that integrate quantum and classical components via workflow technology [<xref ref-type="bibr" rid="ref-5">5</xref>]; and a quantum software testing framework that addresses post-implementation quality assurance challenges [<xref ref-type="bibr" rid="ref-6">6</xref>]. However, there remains a clear gap in the availability of rigorous theoretical frameworks for the formal design and verification of quantum-specific constraints, particularly the no-cloning theorem. Such a framework is crucial for supporting traditional software engineers, who are experienced in classical software development but often lack expertise in quantum software principles.</p>
<p>This paper presents a metamodeling approach using UML-style notation to describe the no-cloning theorem in quantum mechanics, demonstrating how traditional software engineering techniques can effectively represent and analyze quantum principles. The metamodel defines key quantum concepts related to the no-cloning theorem and their relationships, incorporating formal invariants to reinforce quantum mechanical constraints. Two edge cases&#x2014;conditional copying with CNOT gates and quantum teleportation&#x2014;are examined through instance models to assess the metamodel&#x2019;s effectiveness in analyzing quantum principles. While these cases may seem to violate the no-cloning theorem, the analysis confirms their compliance with its constraints. This metamodeling approach provides a structured framework that integrates quantum mechanics with software engineering, helping traditional software engineers better engage with quantum computing and apply established software engineering methodologies to quantum software development.</p>
<p>The remainder of this paper is structured as follows: <xref ref-type="sec" rid="s2">Section 2</xref> provides an overview of related work. <xref ref-type="sec" rid="s4">Section 4</xref> discusses the no-cloning theorem and introduces the metamodel for the theorem. <xref ref-type="sec" rid="s5">Section 5</xref> describes two edge cases of cloning, captured by instance models of the metamodel and their implementations. <xref ref-type="sec" rid="s8">Section 8</xref> concludes the paper and outlines future research directions.</p>
</sec>
<sec id="s2">
<label>2</label>
<title>Related Work</title>
<p>Recent research in quantum software engineering has focused on applying modeling techniques to quantum computing systems. Alonso et al. [<xref ref-type="bibr" rid="ref-2">2</xref>] developed a unified metamodel for quantum circuits using model-driven engineering, showing how systematic modeling can standardize quantum software development. Following this, S&#x00E1;nchez and Alonso [<xref ref-type="bibr" rid="ref-7">7</xref>] investigated modularity in quantum programming, addressing challenges related to non-clonability and probabilistic operations. Bibbo et al. [<xref ref-type="bibr" rid="ref-8">8</xref>] conducted a comprehensive review of software engineering resources in quantum computing, emphasizing the importance of modeling across the software lifecycle.</p>
<p>The theoretical foundation for quantum software engineering has been developed through several studies. Ahmad et al. [<xref ref-type="bibr" rid="ref-9">9</xref>] discussed the integration of quantum mechanics principles with software engineering practices, particularly focusing on quantum software architectures and their importance in development and validation. Ali et al. [<xref ref-type="bibr" rid="ref-10">10</xref>] analyzed the need for new methodologies that can handle quantum characteristics such as superposition and entanglement. P&#x00E9;rez-Castillo and Piattini [<xref ref-type="bibr" rid="ref-3">3</xref>] proposed a UML profiling mechanism that extends standard UML to support the design of hybrid classical-quantum systems by modeling quantum components, classical-quantum interactions, and system architectures. Piattini et al. [<xref ref-type="bibr" rid="ref-4">4</xref>] present Talavera Manifesto which emphasizes the foundational vision for quantum software engineering (QSE) as a discipline, proposing broad principles and commitments for systematically building, testing, maintaining, and managing quantum software at an industrial scale. Their work advocates for adapting classical software engineering processes to quantum contexts and highlights the importance of governance, quality assurance, reuse, and security. In contrast, the our work provides a much more concrete and technical contribution by introducing a formal metamodel with OCL constraints that captures fundamental quantum mechanical laws, specifically the no-cloning theorem, aiming to prevent conceptual errors at the design phase. Thus, while the Talavera Manifesto lays out a high-level roadmap for the future of QSE as a discipline, our work operationalizes part of that vision by formally modeling quantum-specific constraints that can be directly applied in early-stage quantum software modeling.</p>
<p>Implementation aspects of quantum software systems have been explored through various methods. Sabzevari et al. [<xref ref-type="bibr" rid="ref-11">11</xref>] introduced quantum computing as a service to broaden access to quantum computing resources. Gallardo et al. [<xref ref-type="bibr" rid="ref-12">12</xref>] developed Quirk&#x002B;, a tool that enhances quantum circuit development capabilities. The work by Weder et al. [<xref ref-type="bibr" rid="ref-5">5</xref>] presents a comprehensive lifecycle framework for developing hybrid quantum applications that integrate quantum and classical components. They focus on orchestrating these components through workflow technology and present three interwoven lifecycles: the quantum workflow lifecycle, the classical software lifecycle, and the quantum circuit lifecycle. Their approach emphasizes practical implementation considerations such as deployment, observability, and DevOps practices. In contrast, our work advances the conceptual formalization of quantum mechanical principles, specifically the no-cloning theorem, by introducing a UML-based metamodel with OCL constraints. While both works bridge quantum computing and software engineering, Weder et al. emphasize operational processes, covering the entire application lifecycle, whereas our work concentrates on formalizing specific quantum mechanical principles, enforcing fundamental quantum constraints at the modeling phase to demonstrate how traditional software modeling techniques can be adapted to quantum software development.</p>
<p>Testing and validation in quantum systems present unique challenges. Garcia de la Barrera et al. [<xref ref-type="bibr" rid="ref-13">13</xref>] analyzed existing strategies in quantum software testing, focusing on the inadequacies of classical testing methods for quantum systems. Ali [<xref ref-type="bibr" rid="ref-6">6</xref>] presents an introductory overview of quantum software testing (QST), focusing on the challenges of testing quantum programs due to the unique characteristics of quantum computing (e.g., superposition, entanglement). The work outlines three main topics: quantum computing fundamentals, QST challenges compared to classical software testing, and current QST techniques along with their limitations. Ali specifically highlights specialized testing approaches such as input/output coverage criteria, metamorphic testing, and noise-aware testing for quantum programs. In contrast, our work addresses pre-implementation correctness by formally modeling quantum mechanical constraints&#x2014;specifically the no-cloning theorem&#x2014;through a UML-based metamodel with OCL constraints. Rather than testing quantum software after it is built, our work aims to embed quantum correctness directly into the design phase, preventing conceptual errors at the modeling level. Thus, whereas Ali emphasizes improving the quality assurance process for quantum software, our work emphasizes design-time correctness enforcement rooted in fundamental quantum principles.</p>
<p>Process management in quantum software development has been explored in various studies. Khan et al. [<xref ref-type="bibr" rid="ref-14">14</xref>] examined the integration of agile practices into quantum software development, using interviews with practitioners from multiple countries. Separately, Thompson et al. [<xref ref-type="bibr" rid="ref-15">15</xref>] investigated the use of machine learning with quantum computing, suggesting non-algorithmic approaches to programming that are suited for Noisy Intermediate-Scale Quantum (NISQ) devices.</p>
<p>This diverse body of research highlights the advancing maturity of quantum software engineering. This work builds on these foundations by focusing on the formal representation of the no-cloning theorem through metamodeling, aiming to connect traditional software engineering practices with the development of quantum software systems.</p>
</sec>
<sec id="s3">
<label>3</label>
<title>Comparing with Existing Quantum Computing Modeling Approaches</title>
<p>In this section, we compare the metamodeling approach with quantum circuit diagrams [<xref ref-type="bibr" rid="ref-1">1</xref>], and other quantum software modeling approaches [<xref ref-type="bibr" rid="ref-2">2</xref>,<xref ref-type="bibr" rid="ref-3">3</xref>].</p>
<sec id="s3_1">
<label>3.1</label>
<title>Comparing with Quantum Circuit Diagrams</title>
<p>Quantum circuit diagrams are the de facto standard for representing quantum algorithms and operations, offering a visual syntax that is intuitive for physicists and quantum developers.</p>
<p><xref ref-type="table" rid="table-1">Table 1</xref> presents the differences between the metamodeling approach and quantum circuit diagrams. The metamodeling approach operates at a higher level of abstraction, focusing on the conceptual relationships between quantum constructs such as states, gates, and operations. This abstraction enables software engineers to represent complex theoretical principles, like the no-cloning theorem, in a structured manner. In contrast, quantum circuit diagrams provide a lower-level, implementation-focused view that captures the sequential application of quantum gates on qubits. While effective for illustrating algorithms, they do not represent the underlying theoretical constraints (e.g., no-cloning theorem, unitarity of quantum operations) explicitly.</p>
<table-wrap id="table-1">
<label>Table 1</label>
<caption>
<title>Comparing metamodeling with quantum circuit diagrams</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Feature</th>
<th>Metamodeling approach</th>
<th>Quantum circuit diagrams</th>
</tr>
</thead>
<tbody>
<tr>
<td><bold>Abstraction level</bold></td>
<td>High-level abstraction that captures relationships between quantum concepts</td>
<td>Lower-level representation focused on operation sequence and gate implementation</td>
</tr>
<tr>
<td><bold>Support for constraints</bold></td>
<td>Explicit (e.g., inner product preservation, unitarity)</td>
<td>Implicit or manual</td>
</tr>
<tr>
<td><bold>Formal semantics</bold></td>
<td>Can explicitly encode theoretical constraints (e.g., OCL invariants for no-cloning theorem)</td>
<td>Constraints are implicit in the circuit structure rather than formally stated</td>
</tr>
<tr>
<td><bold>Target audience</bold></td>
<td>Software engineers and system architects familiar with UML</td>
<td>Quantum physicists and algorithm developers</td>
</tr>
<tr>
<td><bold>Relationship expression</bold></td>
<td>Explicitly shows associations, multiplicity, and inheritance between quantum concepts</td>
<td>Primarily shows temporal and operational dependencies</td>
</tr>
<tr>
<td><bold>Integration with SE tools</bold></td>
<td>High (supports model-driven engineering)</td>
<td>Low</td>
</tr>
<tr>
<td><bold>Domain coverage</bold></td>
<td>Can represent the entire conceptual domain including theoretical principles</td>
<td>Focused on computational aspects and executable operations</td>
</tr>
<tr>
<td><bold>Notation</bold></td>
<td>UML-style class diagrams with constraints</td>
<td>Time-sequential gate operations on qubits</td>
</tr>
<tr>
<td><bold>Implementation gap</bold></td>
<td>Requires translation to executable code</td>
<td>Directly represents executable operations</td>
</tr>
<tr>
<td><bold>Extensibility</bold></td>
<td>Easily extended to incorporate new quantum concepts</td>
<td>Extension requires adding new gate types or circuit components</td>
</tr>
<tr>
<td><bold>Expressiveness for theorems</bold></td>
<td>Can express abstract rules (e.g., no-cloning limits)</td>
<td>Shows circuit-level behavior only</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>A key strength of the metamodeling approach is its support for explicitly specifying constraints, such as inner product preservation and unitarity, through Object Constraint Language (OCL) invariants. These formal semantics enable rigorous validation against quantum mechanical rules. Circuit diagrams, however, rely on implicit correctness, with constraint adherence being verified through simulation or domain expertise rather than formal specification.</p>
<p>The intended audiences for these approaches also differ. Metamodeling is primarily suited for software engineers, particularly those working within model-driven engineering environments, whereas quantum circuit diagrams are tailored for physicists and quantum algorithm developers. In terms of expressiveness, metamodels make use of associations, multiplicity, and inheritance to define complex relationships between quantum entities. Circuit diagrams, on the other hand, emphasize operational dependencies and time-ordered execution. Furthermore, the metamodeling approach integrates well with software engineering modeling tools, while circuit diagrams often exist in isolation from such tools.</p>
<p>In terms of domain coverage, metamodels can capture both operational procedures and foundational principles, providing a comprehensive view of quantum systems. Circuit diagrams are generally limited to computational aspects and do not encode theoretical abstractions. The notations also reflect this distinction: metamodels use UML-style diagrams with formal constraints, whereas circuit diagrams depict time-sequential gate operations.</p>
<p>A limitation of metamodeling is the implementation gap&#x2014;it requires translation from model to executable code. In contrast, circuit diagrams represent executable operations directly and can be compiled to run on quantum hardware. However, the extensibility of metamodels is a notable advantage; they can be adapted to include new quantum concepts through standard modeling techniques, while extending circuit diagrams requires the introduction of new gate symbols or custom logic.</p>
<p>Together, the metamodeling approach and quantum circuit diagrams serve complementary roles in quantum software engineering. Metamodels offer a rigorous theoretical framework for design and verification, particularly suited for traditional software engineers working with formal models. In contrast, quantum circuit diagrams provide practical, implementation-oriented representations tailored to the needs of quantum physicists and algorithm developers.</p>
</sec>
<sec id="s3_2">
<label>3.2</label>
<title>Comparing with Other Quantum Software Modeling Approaches</title>
<p>We compare the proposed approach with two existing quantum software modeling approaches: the work of Alonso et al. [<xref ref-type="bibr" rid="ref-2">2</xref>] and that of P&#x00E9;rez-Castillo and Piattini [<xref ref-type="bibr" rid="ref-3">3</xref>]. <xref ref-type="table" rid="table-2">Table 2</xref> presents a detailed comparison.</p>
<table-wrap id="table-2">
<label>Table 2</label>
<caption>
<title>Comparing with other quantum software modeling approaches</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
</colgroup>
<thead>
<tr>
<th align="center">Aspect</th>
<th align="center">Proposed metamodeling approach</th>
<th align="center">Alonso et al.&#x2019;s work [<xref ref-type="bibr" rid="ref-2">2</xref>]</th>
<th align="center">P&#x00E9;rez-Castillo and Piattini&#x2019;s work [<xref ref-type="bibr" rid="ref-3">3</xref>]</th>
</tr>
</thead>
<tbody>
<tr>
<td>Primary focus</td>
<td>Formalizing quantum mechanics principles (specifically the no-cloning theorem)</td>
<td>Unitary circuit model representation</td>
<td>Classical-quantum hybrid systems design</td>
</tr>
<tr>
<td>Modeling notation</td>
<td>UML &#x002B; OCL</td>
<td>Graph-based metamodel (UML-inspired) &#x002B; OCL</td>
<td>UML Profile</td>
</tr>
<tr>
<td>Model extensibility</td>
<td>Extends through inheritance from base metaclasses</td>
<td>Supports five different modeling strategies</td>
<td>Extends UML through standard profiling mechanism</td>
</tr>
<tr>
<td>Quantum elements represented</td>
<td>Quantum states, gates, entanglement, teleportation, cloning, unitarity, orthogonality</td>
<td>Qubits, quantum gates, circuits, control structures</td>
<td>Quantum components, algorithms, gates, qubits</td>
</tr>
<tr>
<td>Constraint language</td>
<td>OCL (Object Constraint Language)</td>
<td>OCL (constraints for validity and model transformations)</td>
<td>UML constraints and stereotypes</td>
</tr>
<tr>
<td>Integration with classical systems</td>
<td>Not explicitly addressed</td>
<td>Primarily focused on quantum circuits</td>
<td>Strong focus on hybrid classical-quantum systems</td>
</tr>
<tr>
<td>Abstraction level</td>
<td>High (conceptual metamodel)</td>
<td>Medium (circuit-level abstractions)</td>
<td>Medium (structural and behavioral UML models)</td>
</tr>
<tr>
<td>Formalism level</td>
<td>High (mathematical concepts with OCL invariants)</td>
<td>Medium (graph-based with OCL constraints)</td>
<td>Medium-Low (standard UML extension)</td>
</tr>
<tr>
<td>Validation focus</td>
<td>Formal validation of cloning constraints and metamodel constraints</td>
<td>Correct circuit structure and gate sequencing</td>
<td>Integration of classical and quantum components</td>
</tr>
<tr>
<td>Supported diagrams</td>
<td>Class diagrams</td>
<td>Graph-based representations</td>
<td>Use case, class, sequence, activity, deployment diagrams</td>
</tr>
<tr>
<td>Modeling strategies</td>
<td>Single approach</td>
<td>Multiple (swim-lane, linear, slice, mixed swim-lane, mixed linear)</td>
<td>Multiple diagram types with consistent stereotypes</td>
</tr>
<tr>
<td>Used tools</td>
<td>StarUML for creating UML models, Qiskit</td>
<td>Eclipse, Qiskit, Py4J, Jython, Epsilon Transformation Language</td>
<td>Papyrus for creating UML models</td>
</tr>
<tr>
<td>Primary contribution</td>
<td>Formal representation of quantum principles</td>
<td>Unified metamodel for quantum circuits</td>
<td>Design methodology for hybrid systems</td>
</tr>
<tr>
<td>Target users</td>
<td>Software engineers interested in quantum software</td>
<td>Quantum circuit designers and MDE practitioners</td>
<td>System architects and hybrid software designers</td>
</tr>
<tr>
<td>Implementation examples</td>
<td>Quantum state cloning examples</td>
<td>Quantum circuit modeling examples</td>
<td>Hybrid application (finance) prototype</td>
</tr>
<tr>
<td>Applicability to other quantum models</td>
<td>Limited (focused on no-cloning theorem)</td>
<td>Primarily unitary circuit model</td>
<td>Applicable to various quantum computing paradigms</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>A notable strength of the proposed approach is its high level of abstraction, employing OCL for formal constraint validation. This enables the explicit formalization of quantum rules such as entanglement and teleportation. It offers a more rigorous formalism than the medium-level circuit abstractions (e.g., quantum gates as graph nodes) in Alonso et al.&#x2019;s method or the medium-low structural focus (e.g., quantum concepts as UML stereotypes) in P&#x00E9;rez-Castillo and Piattini&#x2019;s profile.</p>
<p>From a tooling perspective, all approaches leverage UML-based tools (e.g., StarUML, Papyrus, Eclipse), but their target users differ: the proposed approach is aimed at software engineers interested in quantum software design, while Alonso et al.&#x2019;s and P&#x00E9;rez-Castillo and Piattini&#x2019;s frameworks are intended for quantum circuit developers and hybrid system architects, respectively.</p>
<p>In terms of modeling strategy, the proposed metamodel employs a single, inheritance-based class structure, in contrast to Alonso et al.&#x2019;s multi-strategy graph-based representation (e.g., swim-lane and slice-based graphs) and P&#x00E9;rez-Castillo and Piattini&#x2019;s multi-diagram UML profiling (e.g., class, sequence, and deployment diagrams). However, its scope is narrower, being tailored to the no-cloning theorem, whereas the other two frameworks offer broader applicability to unitary models or hybrid paradigms.</p>
<p>Validation strategies also differ: the proposed approach focuses on formal validation of cloning constraints, Alonso emphasizes correct circuit structure, and P&#x00E9;rez-Castillo prioritizes classical-quantum component integration.</p>
<p>In summary, the novelty of this work lies in developing a formal metamodel that goes beyond representing quantum concepts to explicitly encode the mathematical constraints of quantum mechanics&#x2014;specifically the no-cloning theorem&#x2014;using verifiable OCL invariants. This enables early-stage validation of quantum software models within established software engineering practices, effectively bridging foundational quantum principles with model-driven software engineering methodologies in a formal and verifiable manner.</p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Metamodeling &#x201C;No-Cloning Theorem&#x201D;</title>
<p>In this section, we discuss the no-cloning theorem and introduce a metamodel that represents it. Theorem 1 [<xref ref-type="bibr" rid="ref-1">1</xref>] details the no-cloning theorem.</p>
<p><bold>Theorem 1</bold> (No-Cloning Theorem): <italic>The no-cloning theorem states that creating an exact copy of an arbitrary unknown quantum state is impossible. This theorem is crucial as it sets fundamental limits on quantum computing and information processing, in contrast to classical mechanics where state duplication is feasible</italic>.</p>
<p><italic>Consider a quantum machine designed to clone quantum states, which includes two slots: slot A (data slot) and slot B (target slot). Slot A contains an unknown pure quantum state <inline-formula id="ieqn-1"><mml:math id="mml-ieqn-1"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, and slot B starts in a standard pure state <inline-formula id="ieqn-2"><mml:math id="mml-ieqn-2"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>. The initial combined state of the system can be represented by <xref ref-type="disp-formula" rid="eqn-1">Eq. (1)</xref>:</italic>
<disp-formula id="eqn-1"><label>(1)</label><mml:math id="mml-eqn-1" display="block"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>.</mml:mo></mml:math></disp-formula><italic>where <inline-formula id="ieqn-3"><mml:math id="mml-ieqn-3"><mml:mo>&#x2297;</mml:mo></mml:math></inline-formula> denotes the tensor product of the states in slots A and B</italic>.</p>
<p><italic>Suppose there is a unitary operation U purported to clone quantum states. Specifically, U is applied to the combined system with the state defined by <xref ref-type="disp-formula" rid="eqn-1">Eq. (1)</xref>. The intended outcome of this operation is to duplicate the state <inline-formula id="ieqn-4"><mml:math id="mml-ieqn-4"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, as shown in <xref ref-type="disp-formula" rid="eqn-2">Eq. (2)</xref>:</italic>
<disp-formula id="eqn-2"><label>(2)</label><mml:math id="mml-eqn-2" display="block"><mml:mi>U</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p><italic>Assuming the cloning process works for states <inline-formula id="ieqn-5"><mml:math id="mml-ieqn-5"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-6"><mml:math id="mml-ieqn-6"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, the effects of the unitary operation can be examined by considering inner products, as shown in <xref ref-type="disp-formula" rid="eqn-3">Eq. (3)</xref>:</italic>
<disp-formula id="eqn-3"><label>(3)</label><mml:math id="mml-eqn-3" display="block"><mml:mtable rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mi>U</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>,</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mi>U</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p><italic>For any two states <inline-formula id="ieqn-7"><mml:math id="mml-ieqn-7"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-8"><mml:math id="mml-ieqn-8"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, a unitary operation U must comply with <xref ref-type="disp-formula" rid="eqn-4">Eq. (4)</xref>:</italic>
<disp-formula id="eqn-4"><label>(4)</label><mml:math id="mml-eqn-4" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>U</mml:mi><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>U</mml:mi><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></disp-formula></p>
<p><italic>This stipulates that the inner product between the states before applying U must equal the inner product between the states after applying U</italic>.</p>
<p><italic>In the hypothetical cloning scenario, before applying the unitary operation U, the states <inline-formula id="ieqn-9"><mml:math id="mml-ieqn-9"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-10"><mml:math id="mml-ieqn-10"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> (the standard state) are combined using tensor products, as are <inline-formula id="ieqn-11"><mml:math id="mml-ieqn-11"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-12"><mml:math id="mml-ieqn-12"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>. The objective of U is to replicate <inline-formula id="ieqn-13"><mml:math id="mml-ieqn-13"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>and <inline-formula id="ieqn-14"><mml:math id="mml-ieqn-14"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>. If successful, after applying U, the states would transform into <inline-formula id="ieqn-15"><mml:math id="mml-ieqn-15"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-16"><mml:math id="mml-ieqn-16"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, respectively. This transformation is represented in <xref ref-type="disp-formula" rid="eqn-5">Eq. (5)</xref>:</italic>
<disp-formula id="eqn-5"><label>(5)</label><mml:math id="mml-eqn-5" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>U</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>U</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></disp-formula></p>
<p><italic>Given the unitarity of U, the following equation holds:</italic>
<disp-formula id="eqn-6"><label>(6)</label><mml:math id="mml-eqn-6" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>U</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>U</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></disp-formula></p>
<p><italic>If we assume cloning is feasible, then <xref ref-type="disp-formula" rid="eqn-5">Eq. (5)</xref> is simplified by <xref ref-type="disp-formula" rid="eqn-6">Eq. (6)</xref> to:</italic>
<disp-formula id="eqn-7"><label>(7)</label><mml:math id="mml-eqn-7" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></disp-formula></p>
<p><italic>Unitary operations must preserve the inner products of states, meaning if U could theoretically clone both <inline-formula id="ieqn-17"><mml:math id="mml-ieqn-17"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-18"><mml:math id="mml-ieqn-18"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, their post-cloning inner products must reflect their original inner products. The inner product between tensor product states <inline-formula id="ieqn-19"><mml:math id="mml-ieqn-19"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> can be decomposed into the product of the inner products of their components due to the separable nature of tensor products in Hilbert spaces, as shown in <xref ref-type="disp-formula" rid="eqn-8">Eq. (8)</xref></italic>.
<disp-formula id="eqn-8"><label>(8)</label><mml:math id="mml-eqn-8" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></disp-formula><italic>where <inline-formula id="ieqn-20"><mml:math id="mml-ieqn-20"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>is the overlap between <inline-formula id="ieqn-21"><mml:math id="mml-ieqn-21"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-22"><mml:math id="mml-ieqn-22"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, and <inline-formula id="ieqn-23"><mml:math id="mml-ieqn-23"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> is the self-inner product of <inline-formula id="ieqn-24"><mml:math id="mml-ieqn-24"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>. Assuming <inline-formula id="ieqn-25"><mml:math id="mml-ieqn-25"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>is normalized, <inline-formula id="ieqn-26"><mml:math id="mml-ieqn-26"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, leading to <xref ref-type="disp-formula" rid="eqn-9">Eq. (9)</xref></italic>.
<disp-formula id="eqn-9"><label>(9)</label><mml:math id="mml-eqn-9" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></disp-formula></p>
<p><italic>This result shows that the similarity or overlap between the tensor product states <inline-formula id="ieqn-27"><mml:math id="mml-ieqn-27"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-28"><mml:math id="mml-ieqn-28"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> is determined solely by the overlap between <inline-formula id="ieqn-29"><mml:math id="mml-ieqn-29"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-30"><mml:math id="mml-ieqn-30"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, with the normalized state <inline-formula id="ieqn-31"><mml:math id="mml-ieqn-31"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> having no impact on the comparison</italic>.</p>
<p><italic>After applying U, <xref ref-type="disp-formula" rid="eqn-10">Eq. (10)</xref> is established since the tensor product of inner products is the product of the inner products</italic>.
<disp-formula id="eqn-10"><label>(10)</label><mml:math id="mml-eqn-10" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo>&#x2297;</mml:mo><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:msup><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mn>2</mml:mn></mml:msup></mml:math></disp-formula></p>
<p><italic>Then, <xref ref-type="disp-formula" rid="eqn-9">Eq. (9)</xref> simplifies to <xref ref-type="disp-formula" rid="eqn-11">Eq. (11)</xref></italic>.
<disp-formula id="eqn-11"><label>(11)</label><mml:math id="mml-eqn-11" display="block"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:msup><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mn>2</mml:mn></mml:msup></mml:math></disp-formula></p>
<p><italic>This equation holds true only if <inline-formula id="ieqn-32"><mml:math id="mml-ieqn-32"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula> or <inline-formula id="ieqn-33"><mml:math id="mml-ieqn-33"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, indicating that <inline-formula id="ieqn-34"><mml:math id="mml-ieqn-34"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-35"><mml:math id="mml-ieqn-35"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> must be either the same state or orthogonal states. This result demonstrates that a unitary cloner can effectively operate for two states only if those states are either identical or orthogonal. For orthogonal states, the inner product is zero, which means there is no overlap between the states and they are perfectly distinguishable with a probability of 1 upon measurement. This ensures a 100% probability of correctly identifying the state as either <inline-formula id="ieqn-36"><mml:math id="mml-ieqn-36"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> or <inline-formula id="ieqn-37"><mml:math id="mml-ieqn-37"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03D5;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> without confusion. Orthogonality before applying a unitary operation implies they must remain orthogonal afterward</italic>.</p>
<p><italic>However, for general quantum states that are neither orthogonal nor identical, no such unitary cloner U can exist, as no unitary operation can satisfy this equation for all possible pairs of states, thereby negating the possibility of a universal cloner. When states are non-orthogonal, they have a non-zero probability amplitude overlap, indicating they cannot be perfectly distinguished by any measurement. Non-orthogonal states, due to their inherent overlap, cannot be perfectly cloned as this would necessitate altering the inner product, which is invariant under unitary evolution. This fundamental limitation applies to both pure and mixed states</italic>.</p>

<p><xref ref-type="fig" rid="fig-1">Fig. 1</xref> illustrates a metamodel for the no-cloning theorem in quantum mechanics using UML-style notation to outline quantum concepts, their relationships, and multiplicity constraints. The model was developed using StarUML<xref ref-type="fn" rid="fn-1"><sup>1</sup></xref><fn id="fn-1"><label>1</label>
<p><ext-link ext-link-type="uri" xlink:href="https://staruml.io">https://staruml.io</ext-link> (accessed on 25 May 2025).</p></fn>, a UML modeling tool. The <monospace>Clone</monospace> metaclass represents hypothetical cloning operations, adhering to the no-cloning principle as specified in Invariant <xref ref-type="disp-formula" rid="eqn-14">(14)</xref>, which allows only identical or orthogonal states to be cloned. The <monospace>Matrix</monospace> metaclass depicts the matrix representation of quantum operations, with Invariant <xref ref-type="disp-formula" rid="eqn-13">(13)</xref> ensuring that these operations are unitary by requiring that the product of a matrix and its conjugate transpose yields the identity matrix. The model includes quantum gates such as the <monospace>Hadamard</monospace>, <monospace>CNOT</monospace>, <monospace>X</monospace>, and <monospace>Z</monospace> gates, and the <monospace>Teleportation</monospace> metaclass, which represents an operation that uses entanglement and classical communication to transfer a quantum state from a source qubit to a target qubit without direct cloning. These teleportation interactions are linked through associations to <monospace>Qubit</monospace>, <monospace>Entanglement</monospace>, and <monospace>ClassicalCommunicationLine</monospace>, capturing the structural dependencies necessary for modeling the protocol. Orthogonality between states is represented through a self-association on the <monospace>State</monospace> metaclass, indicating that two states involved in a cloning operation must satisfy the orthogonality condition when not identical. <xref ref-type="table" rid="table-3">Table 3</xref> provides descriptions of the individual metaclasses represented in the metamodel.</p>
<fig id="fig-1">
<label>Figure 1</label>
<caption>
<title>Metamodel for no-cloning theorem</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66190-fig-1.tif"/>
</fig><table-wrap id="table-3">
<label>Table 3</label>
<caption>
<title>Elements of the no-cloning theorem metamodel in <xref ref-type="fig" rid="fig-1">Fig. 1</xref></title>
</caption>
<table>
<colgroup>
<col/>
<col align="center"/>
</colgroup>
<thead>
<tr>
<th>Metaclass</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><monospace>Matrix</monospace></td>
<td>Represents the mathematical matrix form of quantum operations with linear algebraic transformations (e.g., identity, adjoint) used in operations.</td>
</tr>
<tr>
<td><monospace>Operation</monospace></td>
<td>Abstract class representing quantum operations that transform quantum states (e.g., gates, teleportation).</td>
</tr>
<tr>
<td><monospace>Qubit</monospace></td>
<td>Represents quantum bits, the basic unit of quantum information. It can be in superposition or entangled with other qubits.</td>
</tr>
<tr>
<td><monospace>State</monospace></td>
<td>Represents the quantum state of a qubit with inner product functionality.</td>
</tr>
<tr>
<td><monospace>Gate</monospace></td>
<td>Abstract class for quantum gates (e.g., X, Z, Hadamard, CNOT) that manipulate qubit states.</td>
</tr>
<tr>
<td><monospace>Z</monospace></td>
<td>Z-gate, a specific single-qubit quantum gate that applies a phase flip.</td>
</tr>
<tr>
<td><monospace>X</monospace></td>
<td>X-gate, a specific single-qubit quantum gate that applies a bit flip.</td>
</tr>
<tr>
<td><monospace>Hadamard</monospace></td>
<td>Quantum gate that creates superposition by transforming basis states.</td>
</tr>
<tr>
<td><monospace>CNOT</monospace></td>
<td>Controlled-NOT gate that entangles two qubits</td>
</tr>
<tr>
<td><monospace>Measurement</monospace></td>
<td>Represents the process of measuring quantum states, causing state collapse.</td>
</tr>
<tr>
<td><monospace>Superposition</monospace></td>
<td>Represents the quantum property that a qubit exists in a linear combination of basis states; marked as necessary for certain operations through associations with explicit multiplicity constraints.</td>
</tr>
<tr>
<td><monospace>Entanglement</monospace></td>
<td>Represents quantum correlation between multiple qubits; required in operations like teleportation.</td>
</tr>
<tr>
<td><monospace>Clone</monospace></td>
<td>Represents hypothetical cloning operations, constrained by the no-cloning theorem.</td>
</tr>
<tr>
<td><monospace>Teleportation</monospace></td>
<td>Represents a composite operation that transfers quantum states using entanglement and classical communication.</td>
</tr>
<tr>
<td><monospace>ClassicalCommunicationLine</monospace></td>
<td>Represents the classical channel required in teleportation</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>We employ the Object Constraint Language (OCL) [<xref ref-type="bibr" rid="ref-16">16</xref>], a companion language to UML, to specify the principles of the no-cloning theorem on relevant metaclasses. Invariant <xref ref-type="disp-formula" rid="eqn-12">(12)</xref> maintains that the inner product of orthogonal states must be zero, emphasizing the uniqueness and independence of orthogonal quantum states in cloning operations.
<disp-formula id="eqn-12"><label>(12)</label><mml:math id="mml-eqn-12" display="block"><mml:mtable columnalign="left" rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Context</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>Clone</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Inv</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>InnerProductPreservation</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.Qubit</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext mathvariant="bold">(forAll</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>q1</mml:mtext></mml:mrow><mml:mo>,</mml:mo><mml:mrow><mml:mtext>q2</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2223;</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">if&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>q1.State.orthogonal</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext mathvariant="bold">includes</mml:mtext></mml:mrow><mml:mrow><mml:mtext>(q2.State)</mml:mtext></mml:mrow><mml:mrow><mml:mtext mathvariant="bold">then</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext>q1.State.innerProduct</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>q2.State</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">else</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext>true</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Invariant <xref ref-type="disp-formula" rid="eqn-13">(13)</xref> ensures the unitarity of matrices within the system, a fundamental property in quantum mechanics that governs state evolution. Notably, unitarity is a sufficient condition for general inner product preservation across quantum operations. In contrast, Invariant <xref ref-type="disp-formula" rid="eqn-12">(12)</xref>, defined specifically in the context of cloning, explicitly enforces that inner products between orthogonal states must be preserved in hypothetical cloning operations, reflecting a core constraint of the no-cloning theorem.
<disp-formula id="eqn-13"><label>(13)</label><mml:math id="mml-eqn-13" display="block"><mml:mtable columnalign="left" rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Context</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>Matrix</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Inv</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>Unitarity</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>(self.multiply(self.adjoint())</mml:mtext></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mtext>Matrix::identity()</mml:mtext></mml:mrow><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">and</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.adjoint().multiply(self))</mml:mtext></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mtext>Matrix::identity()</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Invariant <xref ref-type="disp-formula" rid="eqn-14">(14)</xref> enforces the no-cloning theorem by ensuring that no universal cloning operation can replicate all quantum states. It specifies that for any cloning operation, if two qubits have distinct states, they must remain distinct unless they are orthogonal. If orthogonal, the operation may result in the states becoming identical, reflecting the ability to clone states only when their orthogonal relationship is predefined, and prior knowledge of the states is available.
<disp-formula id="eqn-14"><label>(14)</label><mml:math id="mml-eqn-14" display="block"><mml:mtable columnalign="left" rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Context</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>Clone</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Inv</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>CloneInvariant</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.qubit</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext mathvariant="bold">forAll</mml:mtext></mml:mrow><mml:mrow><mml:mtext>(q1, q2</mml:mtext></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">let&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>s1:State= q1.State,</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>s2:State =q2.State</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>&#xA0;in</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">if&#xA0;</mml:mtext></mml:mrow><mml:mi>s</mml:mi><mml:mn>1</mml:mn><mml:mo>&#x2260;</mml:mo><mml:mi>s</mml:mi><mml:mn>2</mml:mn><mml:mrow><mml:mtext mathvariant="bold">then&#xA0;</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">(not&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>self.applyTensor(s1, s2) = s1.tensor(s1)</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext mathvariant="bold">and</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">not&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>self.applyTensor(s1, s2) = s2.tensor(s2))</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext mathvariant="bold">or</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>s1.orthogonal</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext mathvariant="bold">includes&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>(s2)</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext mathvariant="bold">implies</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.applyTensor(s1, s2) = s1.tensor(s1)</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext mathvariant="bold">or</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.applyTensor(s1, s2) = s2.tensor(s2))</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="bold">else</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext>true</mml:mtext></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Invariant <xref ref-type="disp-formula" rid="eqn-15">(15)</xref> ensures that any <monospace>Entanglement</monospace> associated with a <monospace>Teleportation</monospace> operation involves only those <monospace>Qubit</monospace> instances that participate in the <monospace>Teleportation</monospace>. This constraint enforces consistency between the qubits engaged in the teleportation protocol and those entangled as part of its implementation.
<disp-formula id="eqn-15"><label>(15)</label><mml:math id="mml-eqn-15" display="block"><mml:mtable columnalign="left" rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Context</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>Teleportation</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Inv</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>TeleportationEntanglement</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.Entanglement.Qubit</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext mathvariant="bold">forAll</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>q</mml:mtext></mml:mrow><mml:mo>&#x2223;</mml:mo><mml:mrow><mml:mtext>self.Qubit</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext>includes</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>q</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>In teleportation, the receiving (target) qubit is adjusted to replicate the original state through classical communication. Invariant <xref ref-type="disp-formula" rid="eqn-16">(16)</xref> ensures that the target qubit of a teleportation operation is included among the qubits associated with its corresponding classical communication line.
<disp-formula id="eqn-16"><label>(16)</label><mml:math id="mml-eqn-16" display="block"><mml:mtable columnalign="left" rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Context</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>Teleportation</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Inv</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>TeleportationCommunication</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.ClassicalCommunicationLine.Qubit</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext mathvariant="bold">includes</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>self.target</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Invariant <xref ref-type="disp-formula" rid="eqn-17">(17)</xref> ensures that the original quantum state is destroyed during the Bell-state measurement phase of teleportation. It prohibits the coexistence of the original and teleported quantum states, thereby preventing any implicit or residual duplication of state information.
<disp-formula id="eqn-17"><label>(17)</label><mml:math id="mml-eqn-17" display="block"><mml:mtable columnalign="left" rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Context</mml:mtext></mml:mrow><mml:mo>:</mml:mo><mml:mrow><mml:mtext>Teleportation</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Inv:TeleportationDestruction</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.source.Measurement</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext>notEmpty()</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext mathvariant="bold">implies</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext>self.source.State.oclIsUndefined()</mml:mtext></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>While the proposed metamodel provides a structural foundation for representing key quantum computing concepts, it is important to acknowledge its limitations in directly modeling dynamic phenomena such as quantum state evolution. Quantum state evolution, governed by continuous unitary transformations and probabilistic measurement collapses, involves temporal and process-oriented behaviors that static structural metamodels, such as those based on UML, are not inherently designed to capture. However, relevant constraints associated with quantum state evolution (e.g., unitarity, inner product preservation) can be formally expressed through OCL, as demonstrated. Similarly, while the no-cloning impossibility is captured in the proposed metamodel through a dedicated <monospace>Clone</monospace> metaclass and associated OCL invariants, the enforcement of no-cloning across dynamic sequences of operations exceeds the expressiveness of static class diagrams.</p>
<p>The no-cloning theorem forms a fundamental basis for quantum computing and is explicitly integrated into the design of the proposed metamodel; therefore, it does not adversely affect model interoperability. Any models developed based on the metamodel remain inherently interoperable by design. In current quantum computing practice, modularity is typically defined at the level of operations and algorithms, both of which are explicitly represented within the metamodel, thereby ensuring strong modularity support. We anticipate that the metamodel will continue to evolve and expand to encompass a broader range of quantum computing aspects, enhancing its flexibility and applicability for developing diverse quantum software systems.</p>
<p>The no-cloning theorem is a fundamental law of quantum mechanics and does not directly impact model qualities such as reusability. Model qualities are typically determined at the instance-level (design-level) of the metamodel by applying software engineering principles such as coupling, cohesion, and separation of concerns, as established in traditional software engineering. The applicability of these traditional principles to quantum software systems remains an open area for further investigation. Once reusability is intentionally designed at the model-level, it is inherently reflected in the construction of programming components at the implementation-level.</p>
<p>In quantum communication systems (e.g., quantum teleportation, entanglement swapping [<xref ref-type="bibr" rid="ref-1">1</xref>]), which transmit information between two or more parties using quantum phenomena such as superposition and entanglement, the constraints imposed by the no-cloning theorem can be used to reason about the impossibility of duplicating qubit states during information transfer. The metamodel helps structurally represent these systems while formally enforcing no-cloning constraints through OCL invariants, thereby enabling systematic validation of quantum communication protocols to ensure they adhere to fundamental quantum mechanical principles.</p>
<p>The metamodel can be extended to support approximate or probabilistic cloning techniques (e.g., universal quantum cloning machines (UQCM) [<xref ref-type="bibr" rid="ref-17">17</xref>]), which allow the creation of imperfect copies of quantum states by relaxing the strict limitations of the no-cloning theorem at the cost of reduced fidelity. This can be achieved by extending the <monospace>Clone</monospace> metaclass into a hierarchy representing different types of cloning: perfect cloning (strictly prohibited by the no-cloning theorem for arbitrary unknown states), approximate cloning (allowing imperfect copies with reduced fidelity), and probabilistic cloning (allowing perfect copies but only with a certain probability). Depending on how these extended elements are incorporated into the model, the fidelity of quantum simulations may vary, with approximate cloning introducing fidelity degradation and probabilistic cloning introducing conditional success rates. Such extensions would enhance the metamodel&#x2019;s practical applicability to real-world quantum systems where noise and imperfections exist.</p>
</sec>
<sec id="s5">
<label>5</label>
<title>Presenting Cloning-Like Operations as Instance Models of Metamodel</title>
<p>This section examines two edge cases &#x2013; conditional copying using CNOT gates and quantum teleportation &#x2013; through instance models to evaluate the metamodel&#x2019;s effectiveness in analyzing quantum principles. All instance models were created using StarUML. These two scenarios were selected based on the following criteria: (1) both are canonical operations in quantum computing that are commonly misinterpreted as potential violations of the no-cloning theorem, and (2) each exercises distinct aspects of the metamodel and its associated OCL invariants. The CNOT case specifically tests constraints related to orthogonality and conditional behavior (e.g., Invariants <xref ref-type="disp-formula" rid="eqn-12">(12)</xref> and <xref ref-type="disp-formula" rid="eqn-14">(14)</xref>), while the teleportation case engages constraints involving state destruction, entanglement, and classical communication consistency (e.g., Invariants <xref ref-type="disp-formula" rid="eqn-15">(15)</xref>&#x2013;<xref ref-type="disp-formula" rid="eqn-17">(17)</xref>). Together, these cases probe the boundary conditions of cloning behavior and validate the internal consistency of the metamodel&#x2019;s formal constraints.</p>
<sec id="s5_1">
<label>5.1</label>
<title>Conditional Cloning Using CNOT Gate</title>
<p>Unitary operations preserve inner products, allowing only orthogonal states known prior to cloning to be perfectly cloned without violating the no-cloning theorem. Orthogonality is essential for maintaining consistency with quantum laws, particularly in preserving probability amplitudes and ensuring state distinguishability. A specific example is the CNOT gate, which acts as a cloning operation under certain conditions.</p>
<p>Applying a CNOT gate to two qubits where the control qubit is <inline-formula id="ieqn-38"><mml:math id="mml-ieqn-38"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and the target qubit is <inline-formula id="ieqn-39"><mml:math id="mml-ieqn-39"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, orthogonal to <inline-formula id="ieqn-40"><mml:math id="mml-ieqn-40"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, results in the target flipping to <inline-formula id="ieqn-41"><mml:math id="mml-ieqn-41"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, simulating conditional copying of the control bit. While <inline-formula id="ieqn-42"><mml:math id="mml-ieqn-42"><mml:mi>C</mml:mi><mml:mi>N</mml:mi><mml:mi>O</mml:mi><mml:mi>T</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> &#x003D; <inline-formula id="ieqn-43"><mml:math id="mml-ieqn-43"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> might suggest cloning, the non-replication in scenarios where the control is <inline-formula id="ieqn-44"><mml:math id="mml-ieqn-44"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and the target is <inline-formula id="ieqn-45"><mml:math id="mml-ieqn-45"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, <inline-formula id="ieqn-46"><mml:math id="mml-ieqn-46"><mml:mi>C</mml:mi><mml:mi>N</mml:mi><mml:mi>O</mml:mi><mml:mi>T</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> results in <inline-formula id="ieqn-47"><mml:math id="mml-ieqn-47"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, demonstrates the conditional and non-universal nature of this operation, aligning with the no-cloning theorem. Moreover, when the control qubit is initialized in a superposition <inline-formula id="ieqn-48"><mml:math id="mml-ieqn-48"><mml:mi>&#x03B1;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>+</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> and the target qubit is initialized in <inline-formula id="ieqn-49"><mml:math id="mml-ieqn-49"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, the CNOT gate produces an entangled state <inline-formula id="ieqn-50"><mml:math id="mml-ieqn-50"><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>+</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2297;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>+</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> rather than two independent copies. Thus, the CNOT gate operation preserves the no-cloning theorem by preventing universal replication of arbitrary quantum states. Accordingly, the metamodel distinguishes the <monospace>CNOT</monospace> gate from the <monospace>Clone</monospace> metaclass to capture these nuances.</p>
<p><xref ref-type="fig" rid="fig-2">Fig. 2</xref> presents an instance model of the metamodel illustrating this conditional simulation of cloning, highlighting that CNOT&#x2019;s copying is situationally dependent and not a form of true cloning. The instance model for conditional cloning using the CNOT gate concretely demonstrates how a control-target configuration enables replication of basis states. In this model, qubit <monospace>q1</monospace> is initialized to the orthogonal basis state <inline-formula id="ieqn-51"><mml:math id="mml-ieqn-51"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>&#x2014;a critical condition for the operation&#x2019;s validity within the no-cloning theorem&#x2014;while <monospace>q2</monospace> is initialized to <inline-formula id="ieqn-52"><mml:math id="mml-ieqn-52"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>. The CNOT gate, with <monospace>q1</monospace> as control and <monospace>q2</monospace> as target, conditionally flips the target qubit based on the control qubit&#x2019;s state. As a result, when the control qubit is in <inline-formula id="ieqn-53"><mml:math id="mml-ieqn-53"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, the target qubit transitions from <inline-formula id="ieqn-54"><mml:math id="mml-ieqn-54"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> to <inline-formula id="ieqn-55"><mml:math id="mml-ieqn-55"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, effectively mirroring the control state. This structural arrangement demonstrates how the CNOT operation facilitates controlled state transfer when specific preconditions are met, namely, when predetermined orthogonal states are involved. This validates that conditional cloning of orthogonal basis states can be achieved exactly. The model effectively captures that the CNOT gate does not perform universal cloning (which would violate quantum principles) but instead carries out a conditional copying operation that depends entirely on the initial states of the qubits being known in advance. This implies that if the control qubit is initialized in the <inline-formula id="ieqn-56"><mml:math id="mml-ieqn-56"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> state or in a superposition state, perfect cloning would not occur, consistent with the no-cloning theorem. Thus, the instance model provides concrete evidence of how conditional operations achieve exact cloning for basis states while respecting the fundamental quantum mechanical constraints imposed by the no-cloning theorem for general states.</p>
<fig id="fig-2">
<label>Figure 2</label>
<caption>
<title>Conditional cloning of states using the CNOT gate</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66190-fig-2.tif"/>
</fig>
<p>The instance of the metamodel that demonstrates conditional cloning using the CNOT gate is detailed in <xref ref-type="fig" rid="fig-6">Listing 1</xref>. The program initializes two qubits, [0] and [1], in state <inline-formula id="ieqn-57"><mml:math id="mml-ieqn-57"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> (line 8). An <monospace>X</monospace> gate is applied to qubit [0] to transition it to <inline-formula id="ieqn-58"><mml:math id="mml-ieqn-58"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> (line 13), making it orthogonal to qubit [1]. A <monospace>cx (CNOT)</monospace> gate then correlates qubit [0] (control) with qubit [1] (target) (line 16), flipping qubit [1] to <inline-formula id="ieqn-59"><mml:math id="mml-ieqn-59"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> if qubit [0] is <inline-formula id="ieqn-60"><mml:math id="mml-ieqn-60"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, thereby simulating cloning in this controlled setup. The qubits are measured (line 19), and the circuit is run 1000 times using Aer&#x2019;s qasm simulator (lines 22&#x2013;27) to gather the outcomes (lines 30&#x2013;31).</p>
<fig id="fig-6">
<label>Listing 1</label>
<caption>
<title>Simulating cloning of orthogonal states using the CNOT gate</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66190-fig-6.tif"/>
</fig>
<p>The program leads to the measurement outcome &#x2018;11&#x2019; with a consistent count of 1000. This indicates that both qubits were measured in state <inline-formula id="ieqn-61"><mml:math id="mml-ieqn-61"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> in all trials, demonstrating conditional cloning under known configurations, consistent with the no-cloning theorem.</p>
</sec>
<sec id="s5_2">
<label>5.2</label>
<title>State Transfer via Teleportation</title>
<p>Quantum teleportation presents another nuanced case with respect to the no-cloning theorem. It involves transferring a quantum state from one particle to another without physically moving the particles themselves. The process utilizes entanglement between particles to transmit an arbitrary quantum state across different locations, a Bell-state measurement to identify the necessary correction operations, and classical communication to adjust the receiving qubit&#x2019;s state to reproduce the original state. Although teleportation might appear similar to cloning, it adheres to the no-cloning theorem by preventing duplication: the original quantum state is destroyed during the measurement process, ensuring that only a single copy of the state exists at any time.</p>
<p><xref ref-type="fig" rid="fig-3">Fig. 3</xref> displays a metamodel instance illustrating teleportation. The diagram outlines the interactions among three qubits (q1, q2, and q3) involving superposition, entanglement, and measurements to replicate the state of q1 in q3. Each qubit&#x2019;s operation is sequentially marked (e.g., 1, 2, 3, etc.) to show the order and dependencies within the teleportation protocol. Initially, q1 is set to the superposition state <inline-formula id="ieqn-62"><mml:math id="mml-ieqn-62"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> using a Hadamard gate, while q2, also brought to superposition by a Hadamard gate, is entangled with q3, initially in <inline-formula id="ieqn-63"><mml:math id="mml-ieqn-63"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, using another Hadamard and a CNOT gate. This setup prepares the quantum states for subsequent entanglement and teleportation, depicted through connections that illustrate the correlation between the qubits. A Bell-state measurement on q1 and q2 then collapses the system into one of the four Bell states, each representing a maximally entangled state. Below are descriptions of the four Bell states:</p>
<p><list list-type="bullet">
<list-item>
<p>Outcome &#x2018;00&#x2019;: <inline-formula id="ieqn-64"><mml:math id="mml-ieqn-64"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msup><mml:mi mathvariant="normal">&#x03A6;</mml:mi><mml:mo>+</mml:mo></mml:msup><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:msqrt><mml:mn>2</mml:mn></mml:msqrt></mml:mfrac><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>00</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>+</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>11</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> This outcome indicates no flips or phase changes are necessary. When the measurement results in &#x2018;00&#x2019;, it suggests that qubits q1 and q2 were measured in a state maintaining their original correlation, without any phase or bit flips. Thus, qubit q3 will not require any corrections to match the original state of q1.</p></list-item>
<list-item>
<p>Outcome &#x2018;01&#x2019;: <inline-formula id="ieqn-65"><mml:math id="mml-ieqn-65"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msup><mml:mi mathvariant="normal">&#x03A6;</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:msqrt><mml:mn>2</mml:mn></mml:msqrt></mml:mfrac><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>00</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2212;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>11</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> The negative sign indicates a phase difference. Specifically, the &#x2018;01&#x2019; outcome tells us that qubits q1 and q2 were measured in states that lead to a phase flip relative to their original superposition states. The Z gate is a phase flip gate, which introduces a phase shift of <inline-formula id="ieqn-66"><mml:math id="mml-ieqn-66"><mml:mi>&#x03C0;</mml:mi></mml:math></inline-formula> (or changes the sign of the amplitude) in the <inline-formula id="ieqn-67"><mml:math id="mml-ieqn-67"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> component of a qubit&#x2019;s state. When we measure &#x2018;01&#x2019;, it means the phase information has been altered, and to correct it back to the original state, we need to apply the Z gate (relative phase of <inline-formula id="ieqn-68"><mml:math id="mml-ieqn-68"><mml:mi>&#x03C0;</mml:mi></mml:math></inline-formula>).</p></list-item>
<list-item>
<p>Outcome &#x2018;10&#x2019;: <inline-formula id="ieqn-69"><mml:math id="mml-ieqn-69"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msup><mml:mi mathvariant="normal">&#x03A8;</mml:mi><mml:mo>+</mml:mo></mml:msup><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:msqrt><mml:mn>2</mml:mn></mml:msqrt></mml:mfrac><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>01</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>+</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>10</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>. This outcome signifies a bit flip has occurred. The &#x2018;10&#x2019; measurement indicates that qubits q1 and q2 had their bits flipped relative to their entangled partners, necessitating a bit flip (X gate) correction on qubit q3 to align with the original state of q1. The X gate inverts the state from <inline-formula id="ieqn-70"><mml:math id="mml-ieqn-70"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> to <inline-formula id="ieqn-71"><mml:math id="mml-ieqn-71"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula> or vice versa.</p></list-item>
<list-item>
<p>Outcome &#x2018;11&#x2019;: <inline-formula id="ieqn-72"><mml:math id="mml-ieqn-72"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msup><mml:mi mathvariant="normal">&#x03A8;</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:msqrt><mml:mn>2</mml:mn></mml:msqrt></mml:mfrac><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>01</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2212;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>10</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> This outcome implies both a bit and phase flip. The &#x2018;11&#x2019; result indicates that qubits q1 and q2 were measured in a state that not only swapped their original bits but also introduced a phase shift. To correct this, a combination of the X and Z gates must be applied to qubit q3. The X gate will address the bit flip, and the Z gate will correct the phase inversion.</p></list-item>
</list></p>
<fig id="fig-3">
<label>Figure 3</label>
<caption>
<title>Teleportation cloning</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66190-fig-3.tif"/>
</fig>
<p>This instance model demonstrates the rigorous enforcement of the constraints of the no-cloning theorem and teleportation specified in the metamodel. The entanglement of qubits enforces Invariant <xref ref-type="disp-formula" rid="eqn-15">(15)</xref>, ensuring consistency between the entangled qubits. The structural representation of <monospace>ClassicalCommunicationLine</monospace> directly aligns with Invariant <xref ref-type="disp-formula" rid="eqn-16">(16)</xref>, which requires classical communication for proper state reconstruction. The measurement performed on qubit <monospace>q1</monospace> enforces Invariant <xref ref-type="disp-formula" rid="eqn-17">(17)</xref>, ensuring the destruction of the original quantum information. More importantly, the destruction of the original state guarantees adherence to the no-cloning theorem by preventing the duplication of quantum states.</p>
<p>Note that the instance model incorporates stepwise labels to represent the order and dependencies of operations, enabling a limited form of sequential behavior modeling. While this auxiliary feature is specific to the instance level and cannot be captured directly at the metamodel level, it supports simulation-oriented reasoning within the model and highlights the potential for future integration with model execution tools, such as Papyrus Moka<xref ref-type="fn" rid="fn-2"><sup>2</sup></xref><fn id="fn-2"><label>2</label>
<p><ext-link ext-link-type="uri" xlink:href="https://marketplace.eclipse.org/content/papyrus-moka">https://marketplace.eclipse.org/content/papyrus-moka</ext-link> (accessed on 25 May 2025).</p>
</fn>, an fUML (the Foundational UML subset<xref ref-type="fn" rid="fn-3"><sup>3</sup></xref><fn id="fn-3"><label>3</label>
<p><ext-link ext-link-type="uri" xlink:href="https://www.omg.org/spec/FUML/1.4/About-FUML">https://www.omg.org/spec/FUML/1.4/About-FUML</ext-link> (accessed on 25 May 2025).</p>
</fn>) execution engine.</p>
<p>The teleportation process is implemented in the instance model outlined in <xref ref-type="fig" rid="fig-7">Listing 2</xref>. The program sets up a circuit <monospace>qc</monospace> with three qubits and three classical bits (lines 11). Qubit [0] is placed in superposition <inline-formula id="ieqn-73"><mml:math id="mml-ieqn-73"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:msqrt><mml:mn>2</mml:mn></mml:msqrt></mml:mfrac><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>0</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>+</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>1</mml:mn><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> using a Hadamard gate (line 14). Qubit [1], also in superposition, is prepared alongside qubit [2] for entanglement via a CNOT gate, where qubit [1] acts as control and qubit [2] as target (lines 17&#x2013;18). A subsequent CNOT gate entangles qubits [1] and [2] (line 21). A Hadamard gate on qubit [0] prepares it for a Bell-state measurement with qubit [1] (line 22), converting its basis to align with the Bell states for measurement (line 23). Depending on the measurement outcome, corrections are applied to qubit [2]: no correction for &#x2018;00&#x2019;, an X gate for &#x2018;10&#x2019;, a Z gate for &#x2018;01&#x2019;, and both gates for &#x2018;11&#x2019; (lines 27&#x2013;32). These operations utilize the <monospace>c_if</monospace> method, which implements classical communication by conditionally applying quantum operations based on classical register values. This models the classical communication channel required in quantum teleportation protocols, where measurement results must be transmitted via classical means to complete the quantum state transfer process. This adjusts qubit [2]&#x2019;s state to match the originally altered state of qubit [0]. Qubit [2] is measured last (line 35). This setup uses classical values to guide quantum corrections, simulating quantum teleportation by transferring the original state to the target. It does not constitute cloning since the original state of qubit [0] is destroyed during Bell state measurement, adhering to the no-cloning theorem.</p>
<fig id="fig-7">
<label>Listing 2</label>
<caption>
<title>Simulating state transfer via teleportation</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66190-fig-7.tif"/>
</fig>
<p><xref ref-type="fig" rid="fig-4">Fig. 4</xref> shows the output of the teleportation program. The histogram represents counts for eight possible measurement outcomes across three qubits, formatted as &#x201C;qubit [2] qubit [1] qubit [0]&#x201D; (000, 001, 010, etc.), with each outcome occurring roughly 108 to 135 times over 1024 shots. This uniform distribution (about 120&#x2013;130 counts per outcome) reflects the initial equal superposition state, equal probability of Bell-state measurement outcomes, and preservation of the state by corrective operations. Variations in counts, such as 108 vs 135, arise from the probabilistic nature of quantum measurements and are typical of quantum shot noise in experiments. The consistent distribution across outcomes confirms the teleportation protocol&#x2019;s effectiveness, as deviations significantly outside expected ranges would indicate operational failures.</p>
<fig id="fig-4">
<label>Figure 4</label>
<caption>
<title>Histogram of teleportation simulating state transfer</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66190-fig-4.tif"/>
</fig>
</sec>
</sec>
<sec id="s6">
<label>6</label>
<title>Discussion</title>
<p>In this section, we discuss the implicit validation embedded in the approach itself, as well as the practical application of the proposed approach in real-world quantum software engineering contexts.</p>
<sec id="s6_1">
<label>6.1</label>
<title>Validation</title>
<p>The two concrete instance models&#x2014;conditional cloning via CNOT and quantum teleportation&#x2014;serve as empirical validation, demonstrating the practical application of the metamodel in capturing specific scenarios governed by the no-cloning constraint. These examples are grounded in well-established quantum operations and validate the correctness and utility of the metamodel. Their implementation in Qiskit, along with measurable outcomes, provides empirical evidence that software derived from the metamodel conforms to the quantum mechanical principles it is designed to represent.</p>
<p>A more comprehensive validation strategy may involve developing a suite of test cases that explore the boundary conditions of the no-cloning theorem, thereby demonstrating the metamodel&#x2019;s ability to prevent invalid model instantiations&#x2014;such as attempts to clone non-orthogonal, unknown quantum states or to construct teleportation operations that preserve the original state. In addition, user studies with quantum software developers could be conducted to assess the metamodel&#x2019;s practical utility and correctness in real-world quantum software design contexts.</p>
</sec>
<sec id="s6_2">
<label>6.2</label>
<title>Practical Applications of the Proposed Metamodel in Quantum Software Engineering</title>
<p>By formalizing foundational quantum principles&#x2014;such as the no-cloning theorem and teleportation constraints&#x2014;as enforceable OCL invariants, the framework enables early detection of conceptual modeling errors before code implementation. This early-stage validation helps prevent violations of core quantum mechanics that could otherwise lead to failures or inefficiencies in later development phases, supporting reliable design and reduce development time. For example, during quantum circuit modeling, the metamodel ensures the unitary nature of operations, preserving quantum information. In the case of potential cloning operations, the model enforces relevant constraints (e.g., orthogonal states must have zero inner product), thereby ensuring compliance with the no-cloning theorem.</p>
<p>The instance models presented in <xref ref-type="fig" rid="fig-2">Figs. 2</xref> and <xref ref-type="fig" rid="fig-3">3</xref> were manually constructed with careful adherence to the structural and semantic constraints defined in the metamodel, including associations, multiplicity rules, and OCL invariants. Their correctness reflects intentional conformance to the metamodel&#x2019;s design principles. Currently, the metamodel has not been fully implemented or integrated into a modeling tool that actively enforces these constraints. The integration of the metamodel and OCL constraints with existing software engineering tools enables automated enforcement of quantum principles throughout the development lifecycle. UML tools such as Eclipse MetaModelAgent<xref ref-type="fn" rid="fn-4"><sup>4</sup></xref><fn id="fn-4"><label>4</label>
<p><ext-link ext-link-type="uri" xlink:href="https://www.metamodelagent.com">https://www.metamodelagent.com</ext-link> (accessed on 25 May 2025).</p></fn> support domain-specific modeling and OCL constraint checking, making the approach directly applicable within established environments. These tools can automatically validate instance models against defined constraints and provide immediate feedback when quantum principles are violated. For instance, during the modeling of quantum error correction codes, OCL constraints can validate that error syndrome measurements [<xref ref-type="bibr" rid="ref-1">1</xref>] do not inadvertently violate the no-cloning theorem while detecting errors through qubit correlations.</p>

<p>Additionally, many UML-based tools (e.g., StarUML) support code generation from models defined over standard UML metamodels. In a similar manner, the proposed metamodel can act as a bridge between quantum design models and implementation code via a translation framework that maps metamodel elements to constructs in quantum programming languages such as Qiskit<xref ref-type="fn" rid="fn-5"><sup>5</sup></xref><fn id="fn-5">
<label>5</label>
<p><ext-link ext-link-type="uri" xlink:href="https://www.ibm.com/quantum/qiskit">https://www.ibm.com/quantum/qiskit</ext-link> (accessed on 25 May 2025).</p>
</fn> and Cirq<xref ref-type="fn" rid="fn-6"><sup>6</sup></xref><fn id="fn-6">
<label>6</label>
<p><ext-link ext-link-type="uri" xlink:href="https://quantumai.google/cirq">https://quantumai.google/cirq</ext-link> (accessed on 25 May 2025).</p>
</fn>. This enables bidirectional transformations between design and implementation. The implementations in Listings <xref ref-type="fig" rid="fig-6">1</xref> and <xref ref-type="fig" rid="fig-7">2</xref> illustrate how metamodel elements correspond to Qiskit constructs&#x2014;for example, translating a <monospace>Qubit</monospace> element into a qubit initialization, or converting a <monospace>Teleportation</monospace> instance into a full Qiskit script with entangled state preparation, Bell measurements, and conditional operations. This integration supports model-driven development of quantum applications, facilitating both forward engineering (from models to code) and reverse engineering (from code to conceptual models), thereby enhancing maintainability and scalability of quantum software systems.</p>

</sec>
<sec id="s6_3">
<label>6.3</label>
<title>Extensibility</title>
<p>A major benefit of the approach is the extensibility of the metamodel to accommodate other concepts. In this section, we demonstrate the extensibility of the metamodel by extending the metamodel in <xref ref-type="fig" rid="fig-1">Fig. 1</xref> for projective measurement, which is a specific type of quantum measurement that projects the state vector of a qubit onto orthogonal subspaces of a Hilbert space. <xref ref-type="fig" rid="fig-5">Fig. 5</xref> shows the extension.</p>
<fig id="fig-5">
<label>Figure 5</label>
<caption>
<title>Metamodel defining projective measurement</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66190-fig-5.tif"/>
</fig>
<p>The extension shown in the figure models projective measurement as a specialization of the <monospace>Measurement</monospace> metaclass (stereotyped as &#x00AB;<monospace>core&#x00BB;</monospace>) from the base metamodel in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>. Projective measurement operates through orthogonal projectors, represented by the <monospace>Projector</monospace> metaclass. Each projector acts on a quantum <monospace>State</monospace>, producing a transition from a <monospace>pre</monospace> to a <monospace>post</monospace> state, along with a corresponding measurement <monospace>Outcome</monospace>. The <monospace>Outcome</monospace> is recorded as a real eigenvalue (via the <monospace>value</monospace> attribute) and corresponds to an eigenspace in the <monospace>HilbertSpace</monospace> of the observable. The multiplicity of <monospace>1..&#x002A;</monospace> on the <monospace>State</monospace> class indicate that the eigenspace (defined by a given eigenvalue) contains one or more valid quantum states that the system may collapse into upon measurement. The observable itself is captured by the <monospace>HermitianObservable</monospace> metaclass, which generalizes concrete Pauli operators such as <monospace>X</monospace>, <monospace>Y</monospace>, and <monospace>Z</monospace>, each defined over a 2-dimensional Hilbert space. A <monospace>HermitianObservable</monospace> includes multiple projectors via spectral decomposition, as indicated by the multiplicity <monospace>&#x002A;</monospace> on the association with <monospace>Projector</monospace>. Upon measurement, the qubit&#x2019;s state collapses to a normalized post-measurement state aligned with the eigenspace corresponding to the observed eigenvalue. This collapse behavior reflects the physical semantics of projective measurement, governed by the projective postulate, formally defined as follows:
<list list-type="bullet">
<list-item>
<p>Upon measurement, the system collapses to an eigenvalue in the eigenspace corresponding to the observed eigenvalue. This behavior is formally defined by the invariant <xref ref-type="disp-formula" rid="eqn-18">(18)</xref> in OCL.
<disp-formula id="eqn-18"><label>(18)</label><mml:math id="mml-eqn-18" display="block"><mml:mtable columnalign="left" columnspacing="1em" rowspacing="4pt"><mml:mtr><mml:mtd><mml:mtext mathvariant="bold">Context:</mml:mtext><mml:mtext mathvariant="monospace">ProjectiveMeasurement</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mtext mathvariant="bold">Inv:Collapse</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mtext mathvariant="monospace">self.HermitianObservable.Projector</mml:mtext><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mtext mathvariant="monospace">forAll(p |</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mtext mathvariant="monospace">p.pre = self.HermitianObservable.Qubit.State</mml:mtext><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mtext mathvariant="bold">and</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mtext mathvariant="monospace">p.Outcome.correspondence.HilbertSpace = self.Hermitian.HilbertSpace)</mml:mtext></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>

</list-item>
<list-item>
<p>The probability of obtaining outcome <inline-formula id="ieqn-74"><mml:math id="mml-ieqn-74"><mml:mi>i</mml:mi></mml:math></inline-formula> is <inline-formula id="ieqn-75"><mml:math id="mml-ieqn-75"><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, where <inline-formula id="ieqn-76"><mml:math id="mml-ieqn-76"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is the projector associated with eigenvalue <inline-formula id="ieqn-77"><mml:math id="mml-ieqn-77"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>. This rule is formally specified by invariant <xref ref-type="disp-formula" rid="eqn-19">(19)</xref> in OCL.
<disp-formula id="eqn-19"><label>(19)</label><mml:math id="mml-eqn-19" display="block"><mml:mtable columnalign="left" columnspacing="1em" rowspacing="4pt"><mml:mtr><mml:mtd><mml:mtext mathvariant="bold">Context:&#xA0;</mml:mtext><mml:mtext mathvariant="monospace">ProjectiveMeasurement</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mtext mathvariant="bold">Inv:Probability</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mtext mathvariant="monospace">self.HermitianObservable.Projector</mml:mtext><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mtext mathvariant="monospace">forAll(p |</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mtext mathvariant="monospace">p.Outcome.value=</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mstyle scriptlevel="0"><mml:mspace width="1em"></mml:mspace></mml:mstyle><mml:mtext mathvariant="monospace">self.HermitianObservable.Qubit.State.innerProduct(p.apply(p.pre)))</mml:mtext></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
</list-item>
<list-item>
<p>The post-measurement state is <inline-formula id="ieqn-78"><mml:math id="mml-ieqn-78"><mml:mfrac><mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:mrow><mml:mrow><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo></mml:mrow></mml:mfrac></mml:math></inline-formula>, provided <inline-formula id="ieqn-79"><mml:math id="mml-ieqn-79"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2260;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>. This normalization rule is formally specified by invariant <xref ref-type="disp-formula" rid="eqn-20">(20)</xref> in OCL.</p>
<p><disp-formula id="eqn-20"><label>(20)</label><mml:math id="mml-eqn-20" display="block"><mml:mtable columnalign="left" rowspacing="4pt" columnspacing="1em"><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Context:&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext mathvariant="monospace">ProjectiveMeasurement</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext mathvariant="bold">Inv:Normalization</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="monospace">self.HermitianObservable.Projector</mml:mtext></mml:mrow><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mtext mathvariant="monospace">forAll(p |</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="monospace">p.apply(p.pre).norm() \lt &gt; 0 implies</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mspace width="1em" /><mml:mspace width="1em" /><mml:mrow><mml:mtext mathvariant="monospace">p.post = p.apply(p.pre).normalize())</mml:mtext></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>where the <monospace>norm()</monospace> function returns the norm (or length) of the projected state <inline-formula id="ieqn-80"><mml:math id="mml-ieqn-80"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, given by <inline-formula id="ieqn-81"><mml:math id="mml-ieqn-81"><mml:msqrt><mml:mo fence="false" stretchy="false">&#x27E8;</mml:mo><mml:mi>&#x03C8;</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:msqrt></mml:math></inline-formula>. The <monospace>normalize()</monospace> function then returns the corresponding post-measurement state as a unit vector in the same direction as <inline-formula id="ieqn-82"><mml:math id="mml-ieqn-82"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:math></inline-formula>, defined as <inline-formula id="ieqn-83"><mml:math id="mml-ieqn-83"><mml:mfrac><mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo></mml:mrow><mml:mrow><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo></mml:mrow></mml:mfrac></mml:math></inline-formula>, assuming <inline-formula id="ieqn-84"><mml:math id="mml-ieqn-84"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>&#x03C8;</mml:mi><mml:mo fence="false" stretchy="false">&#x27E9;</mml:mo><mml:mo>&#x2260;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>.</p></list-item>
</list></p>
<p>These postulates are fundamental axioms of quantum mechanics and must be satisfied by any correct implementation of projective measurement. In practical quantum computing platforms, such as the <monospace>qasm_simulator</monospace> in Qiskit, these behaviors are implemented natively within the simulation backend.</p>
<p>We acknowledge that modeling other quantum mechanical principles&#x2014;such as the Heisenberg uncertainty principle [<xref ref-type="bibr" rid="ref-1">1</xref>]&#x2014;may pose certain challenges, particularly those that involve operator algebra (e.g., non-commutative observables) and probabilistic semantics (e.g., continuous-valued inequalities). Unlike the no-cloning theorem or projective measurement, the Heisenberg uncertainty principle requires expressing commutation relations and real-valued uncertainty bounds, which are more complex to represent using standard UML/OCL constructs. Capturing such principles may necessitate the introduction of richer mathematical abstractions, such as operator algebras, commutation relations, or even probabilistic logic layers.</p>
</sec>
</sec>
<sec id="s7">
<label>7</label>
<title>Threats to Validity</title>
<p>This section discusses potential threats to the validity of the proposed metamodeling approach, organized according to common validity dimensions: internal validity, external validity, construct validity, and conclusion validity.</p>
<p><bold>Internal Validity.</bold> Internal validity is concerned with the correctness of the metamodel, which relies on the formal representation of quantum mechanical principles using OCL constraints. Any misinterpretation or incomplete formalization of these principles could lead to inaccurate modeling. We mitigated this threat by grounding the constraints in established quantum mechanical formulations [<xref ref-type="bibr" rid="ref-1">1</xref>]. The translation from mathematical notation to OCL introduces another potential source of error. Different interpretations of quantum mechanical equations could result in varying constraint definitions. To address this concern, we provided detailed explanations of the mapping between quantum mathematical formulations and corresponding OCL expressions.</p>
<p><bold>External Validity.</bold> External validity pertains to the generalizability of the metamodel beyond the specific cases analyzed. Although the presented edge cases are representative and grounded in canonical quantum behavior, the applicability of the metamodel to other quantum phenomena&#x2014;such as mixed states, approximate cloning, entanglement distillation, or quantum error correction&#x2014;has not yet been explored. To address this limitation, we demonstrate the extensibility of the metamodel through the incorporation of projective measurement, as discussed in <xref ref-type="sec" rid="s6">Section 6</xref>. Additionally, the validation focused on relatively simple quantum systems with few qubits. While the metamodel and its associated OCL invariants are not directly impacted by system scale&#x2014;since the metamodel abstracts quantum concepts independently of the number of qubits&#x2014;scalability concerns arise primarily at the instance level. As the system grows, an increasing number of metaclass instances (e.g., <monospace>Qubit</monospace>, <monospace>State</monospace>, <monospace>Measurement</monospace>) must be created and managed. This expansion may introduce computational overhead, particularly in evaluating OCL constraints over large collections of instances. Additionally, state explosion may become a practical concern at the instance-level. As quantum systems evolve&#x2014;particularly those involving entangled or superposed states&#x2014;the complexity of instance models increases, making it more difficult to maintain, validate, and reason about their correctness without dedicated tool support.</p>
<p><bold>Construct Validity.</bold> Construct validity concerns whether the metamodel accurately represents the theoretical concepts it is intended to capture&#x2014;in this case, the principles underlying the no-cloning theorem. While the metamodel is grounded in quantum mechanical formalism and includes formal constraints (e.g., unitarity, inner product preservation) via OCL invariants, it may still omit subtle physical nuances (e.g., imperfect gates, noise) not easily formalized in UML-based notation. Additionally, the mapping of inherently mathematical quantum operations to software modeling constructs may lead to oversimplification or loss of semantic nuance.</p>
</sec>
<sec id="s8">
<label>8</label>
<title>Conclusion</title>
<p>This paper employs metamodeling techniques to analyze the no-cloning theorem in quantum mechanics through a UML-style metamodel. This metamodel incorporates essential quantum concepts and relationships relevant to the no-cloning theorem, emphasizing the inability to replicate arbitrary unknown quantum states. It validates its utility with instance models that explore edge cases like conditional copying with CNOT gates and quantum teleportation, ensuring they adhere to the theorem&#x2019;s constraints in line with conventional software engineering practices. This research provides the quantum software engineering community with a structured framework for integrating quantum mechanics into software design, promoting advancements in quantum software development. There is also a potential learning curve for software engineers who may lack quantum mechanics background. This interdisciplinary knowledge gap could limit the approach&#x2019;s adoption. However, by leveraging UML&#x2014;a widely practiced and standardized graphical modeling language in software engineering&#x2014;as the foundation of the approach, the barrier to entry is significantly reduced. UML provides a familiar and intuitive framework for software engineers, allowing them to engage with quantum concepts without requiring deep mathematical expertise. By embedding quantum principles within this modeling paradigm, the approach translates complex mathematical formalisms into structured visual representations and declarative rules. These abstractions serve as conceptual scaffolding, helping learners incrementally develop intuition for quantum behavior without being overwhelmed by the underlying formalism.</p>
<p>Future work will focus on broadening the scope of the metamodel beyond the no-cloning theorem. Specifically, we plan to explore its applicability to other areas of quantum computing such as mixed states, approximate cloning, entanglement distillation, and quantum error correction. These topics introduce additional complexity, including probabilistic behaviors, partial fidelity constraints, and hybrid quantum-classical interactions. Extending the metamodel to represent such phenomena will require incorporating new modeling constructs, constraints, and validation mechanisms, and will serve to assess the scalability, flexibility, and robustness of the approach across a wider range of quantum scenarios. The practical utility of the metamodel for quantum software developers depends on integration with existing quantum development tools and workflows. Currently, most quantum programming relies on circuit-based representations rather than UML-style models. Further work is needed to bridge the gap between the metamodeling approach and practical quantum software development environments. By doing so, we aim to further integrate metamodeling with the evolving needs of quantum software engineering.</p>
</sec>
</body>
<back>
<ack>
<p>The author expresses gratitude to all editors and anonymous reviewers for their insightful comments and suggestions, which have significantly enhanced the quality of this manuscript.</p>
</ack>
<sec>
<title>Funding Statement</title>
<p>The author received no specific funding for this study.</p>
</sec>
<sec sec-type="data-availability">
<title>Availability of Data and Materials</title>
<p>The data and materials supporting the findings of this study are openly available at <ext-link ext-link-type="uri" xlink:href="https://github.com/hanbyul1/No-Cloning-Theorem">https://github.com/hanbyul1/No-Cloning-Theorem</ext-link> (accessed on 25 May 2025).</p>
</sec>
<sec>
<title>Ethics Approval</title>
<p>Not applicable.</p>
</sec>
<sec sec-type="COI-statement">
<title>Conflicts of Interest</title>
<p>The author declares no conflicts of interest to report regarding the present study.</p>
</sec>
<ref-list content-type="authoryear">
<title>References</title>
<ref id="ref-1"><label>[1]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Nielsen</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Chuang</surname> <given-names>IL</given-names></string-name></person-group>. <source>Quantum computation and quantum information</source>. <edition>10th ed</edition>. <publisher-loc>Cambridge, UK</publisher-loc>: <publisher-name>Cambridge University Press</publisher-name>; <year>2010</year>.</mixed-citation></ref>
<ref id="ref-2"><label>[2]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Alonso</surname> <given-names>D</given-names></string-name>, <string-name><surname>S&#x00E1;nchez</surname> <given-names>P</given-names></string-name>, <string-name><surname>&#x00C1;lvarez</surname> <given-names>B</given-names></string-name></person-group>. <article-title>A graph-based approach for modelling quantum circuits</article-title>. <source>Appl Sci</source>. <year>2023</year>;<volume>13</volume>(<issue>21</issue>):<fpage>11794</fpage>. doi:<pub-id pub-id-type="doi">10.3390/app132111794</pub-id>.</mixed-citation></ref>
<ref id="ref-3"><label>[3]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>P&#x00E9;rez-Castillo</surname> <given-names>R</given-names></string-name>, <string-name><surname>Piattini</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Design of classical-quantum systems with UML</article-title>. <source>Computing</source>. <year>2022</year>;<volume>104</volume>(<issue>11</issue>):<fpage>2375</fpage>&#x2013;<lpage>403</lpage>. doi:<pub-id pub-id-type="doi">10.1007/s00607-022-01091-4</pub-id>.</mixed-citation></ref>
<ref id="ref-4"><label>[4]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Piattini</surname> <given-names>M</given-names></string-name>, <string-name><surname>Peterssen</surname> <given-names>G</given-names></string-name>, <string-name><surname>P&#x00E9;rez-Castillo</surname> <given-names>R</given-names></string-name>, <string-name><surname>Hevia</surname> <given-names>JL</given-names></string-name>, <string-name><surname>Serrano</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Hern&#x00E1;ndez</surname> <given-names>G</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>The Talavera Manifesto for quantum software engineering and programming</article-title>. In: <conf-name>1st QANSWER 2020; 2020 Feb 11-12; Talavera de la Reina, Spain</conf-name>. p. <fpage>1</fpage>&#x2013;<lpage>5</lpage>. doi:<pub-id pub-id-type="doi">10.1145/3402127.3402131</pub-id>.</mixed-citation></ref>
<ref id="ref-5"><label>[5]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Weder</surname> <given-names>B</given-names></string-name>, <string-name><surname>Barzen</surname> <given-names>J</given-names></string-name>, <string-name><surname>Leymann</surname> <given-names>F</given-names></string-name>, <string-name><surname>Vietz</surname> <given-names>D</given-names></string-name></person-group>. <chapter-title>Quantum software development lifecycle</chapter-title>. In: <source>Quantum software engineering</source>. <edition>1st</edition> ed. <publisher-loc>Cham, Switzerland</publisher-loc>: <publisher-name>Springer</publisher-name>; <year>2022</year>. p. <fpage>61</fpage>&#x2013;<lpage>83</lpage>. doi:<pub-id pub-id-type="doi">10.1007/978-3-031-05324-5_4</pub-id>.</mixed-citation></ref>
<ref id="ref-6"><label>[6]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Ali</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Quantum software testing 101</article-title>. In: <conf-name>Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings; 2024 Apr 14&#x2013;20; Lisbon, Portugal</conf-name>. p. <fpage>426</fpage>&#x2013;<lpage>7</lpage>.</mixed-citation></ref>
<ref id="ref-7"><label>[7]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>S&#x00E1;nchez</surname> <given-names>P</given-names></string-name>, <string-name><surname>Alonso</surname> <given-names>D</given-names></string-name></person-group>. <article-title>On the definition of quantum programming modules</article-title>. <source>Appl Sci</source>. <year>2021</year>;<volume>11</volume>(<issue>13</issue>):<fpage>5843</fpage>. doi:<pub-id pub-id-type="doi">10.3390/app11135843</pub-id>.</mixed-citation></ref>
<ref id="ref-8"><label>[8]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Bibbo</surname> <given-names>LM</given-names></string-name>, <string-name><surname>Fernandez</surname> <given-names>A</given-names></string-name>, <string-name><surname>Suarez</surname> <given-names>JM</given-names></string-name>, <string-name><surname>Pastor</surname> <given-names>O</given-names></string-name></person-group>. <article-title>Modelling quantum software: an annotated bibliography</article-title>. <source>Memoria Investigaciones En Ingenier&#x00ED;a</source>. <year>2024</year>;<volume>27</volume>(<issue>27</issue>):<fpage>285</fpage>&#x2013;<lpage>301</lpage>. doi:<pub-id pub-id-type="doi">10.36561/ing.27.19</pub-id>.</mixed-citation></ref>
<ref id="ref-9"><label>[9]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Ahmad</surname> <given-names>A</given-names></string-name>, <string-name><surname>Khan</surname> <given-names>AA</given-names></string-name>, <string-name><surname>Waseem</surname> <given-names>M</given-names></string-name>, <string-name><surname>Fahmideh</surname> <given-names>M</given-names></string-name>, <string-name><surname>Mikkonen</surname> <given-names>T</given-names></string-name></person-group>. <article-title>Towards process centered architecting for quantum software systems</article-title>. In: <conf-name>2022 IEEE International Conference on Quantum Software (QSW); 2022 Jul 10&#x2013;16; Barcelona, Spain</conf-name>. p. <fpage>26</fpage>&#x2013;<lpage>31</lpage>.</mixed-citation></ref>
<ref id="ref-10"><label>[10]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Ali</surname> <given-names>S</given-names></string-name>, <string-name><surname>Yue</surname> <given-names>T</given-names></string-name>, <string-name><surname>Abreu</surname> <given-names>R</given-names></string-name></person-group>. <article-title>When software engineering meets quantum computing</article-title>. <source>Commun ACM</source>. <year>2022</year>;<volume>65</volume>(<issue>4</issue>):<fpage>84</fpage>&#x2013;<lpage>8</lpage>.</mixed-citation></ref>
<ref id="ref-11"><label>[11]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Sabzevari</surname> <given-names>MT</given-names></string-name>, <string-name><surname>Esposito</surname> <given-names>M</given-names></string-name>, <string-name><surname>Taibi</surname> <given-names>D</given-names></string-name>, <string-name><surname>Khan</surname> <given-names>AA</given-names></string-name></person-group>. <article-title>QCSHQD: quantum computing as a service for hybrid classical-quantum software development: a vision</article-title>. In: <conf-name>QSE-NE 2024-Proceedings of the 1st ACM International Workshop on Quantum Software Engineering: The Next Evolution; 2024 Jul 16; Porto de Galinhas, Brazil</conf-name>. p. <fpage>7</fpage>&#x2013;<lpage>10</lpage>.</mixed-citation></ref>
<ref id="ref-12"><label>[12]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Gallardo</surname> <given-names>JZ</given-names></string-name>, <string-name><surname>Moguel</surname> <given-names>E</given-names></string-name>, <string-name><surname>Canal</surname> <given-names>C</given-names></string-name>, <string-name><surname>Garcia-Alonso</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Quirk&#x002B;: a tool for quantum software development based on quirk</article-title>. In: <conf-name>2024 IEEE International Conference on Software Analysis, Evolution and Reengineering-Companion (SANER-C); 2024 Mar 12; Rovaniemi, Finland</conf-name>. p. <fpage>151</fpage>&#x2013;<lpage>8</lpage>.</mixed-citation></ref>
<ref id="ref-13"><label>[13]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Garc&#x00ED;a de la Barrera</surname> <given-names>A</given-names></string-name>, <string-name><surname>Garc&#x00ED;a-Rodr&#x00ED;guez de Guzm&#x00E1;n</surname> <given-names>I</given-names></string-name>, <string-name><surname>Polo</surname> <given-names>M</given-names></string-name>, <string-name><surname>Piattini</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Quantum software testing: state of the art</article-title>. <source>J Softw Evol Process</source>. <year>2023</year>;<volume>35</volume>(<issue>4</issue>):<fpage>e2419</fpage>. doi:<pub-id pub-id-type="doi">10.1002/smr.2419</pub-id>.</mixed-citation></ref>
<ref id="ref-14"><label>[14]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Khan</surname> <given-names>AA</given-names></string-name>, <string-name><surname>Akbar</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Ahmad</surname> <given-names>A</given-names></string-name>, <string-name><surname>Fahmideh</surname> <given-names>M</given-names></string-name>, <string-name><surname>Shameem</surname> <given-names>M</given-names></string-name>, <string-name><surname>Lahtinen</surname> <given-names>V</given-names></string-name> <etal>et al</etal></person-group>. <article-title>Agile practices for quantum software development: practitioners&#x2019; perspectives</article-title>. In: <conf-name>2023 IEEE International Conference on Quantum Software (QSW); 2023 Jul 2&#x2013;8; Chicago, IL, USA</conf-name>. p. <fpage>9</fpage>&#x2013;<lpage>20</lpage>.</mixed-citation></ref>
<ref id="ref-15"><label>[15]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Thompson</surname> <given-names>N</given-names></string-name>, <string-name><surname>Steck</surname> <given-names>J</given-names></string-name>, <string-name><surname>Behrman</surname> <given-names>E</given-names></string-name></person-group>. <article-title>A non-algorithmic approach to &#x201C;programming&#x201D; quantum computers via machine learning</article-title>. In: <conf-name>2020 IEEE International Conference on Quantum Computing and Engineering (QCE); 2020 Oct 12&#x2013;16; Denver, CO, USA</conf-name>. p. <fpage>63</fpage>&#x2013;<lpage>71</lpage>.</mixed-citation></ref>
<ref id="ref-16"><label>[16]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><collab>Group OM</collab></person-group>. <article-title>Object constraint language (OCL) version 2.4</article-title>; <year>2014 [Internet]. [cited 2025 Jan 27]</year>. Available from: <ext-link ext-link-type="uri" xlink:href="http://www.omg.org/spec/OCL/2.4">http://www.omg.org/spec/OCL/2.4</ext-link>.</mixed-citation></ref>
<ref id="ref-17"><label>[17]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Buzek</surname> <given-names>V</given-names></string-name>, <string-name><surname>Hillery</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Quantum copying: beyond the no-cloning theorem</article-title>. <comment>arXiv:quant-ph/9607018</comment>. <year>1996</year>.</mixed-citation></ref>
</ref-list>
</back></article>