摘要

目前存在的许多有前途的量子计算应用程序的开发人员正在敦促许多不同领域的公司认真考虑将这项新技术整合到他们的业务中。要使这些应用程序正常运行，不仅需要量子计算机，还需要量子软件。相应地，量子软件工程已经成为一个重要的研究领域，因为它试图应用或改编现有的方法和技术（或提出新的方法和技术）用于量子软件的分析、设计、编码和测试，并在大规模生产中在质量保证方面发挥关键作用。然而，量子软件的设计面临两个主要挑战：软件量子元素的建模必须用高级建模语言完成；以及进一步开发所谓的“混合信息系统”的必要性，它结合了量子和经典软件。为了应对这些挑战，我们首先提出了一个用于分析和设计混合信息系统的量子 UML 配置文件；然后，通过用例、类、序列、活动和部署等各种结构和行为图来证明其适用性。与某些其他特定于量子领域的语言相比，此 UML 配置文件确保符合众所周知的国际标准，该标准得到许多工具的支持，并得到广泛社区的遵循。和部署。与某些其他特定于量子领域的语言相比，此 UML 配置文件确保符合众所周知的国际标准，该标准得到许多工具的支持，并被广泛社区所遵循。

引言

量子计算注定会彻底改变社会解决计算难题的方式，即经典计算机无法在实际、合理的时间范围内解决的一些问题。因此，由于量子计算在许多商业领域有着广泛的应用，例如金融服务和经济、化学模拟和分子设计、医学和药物开发、信息安全、供应链和物流、人工智能等领域，因此量子计算受到越来越多的关注。

尽管量子计算已经初步展示了其进步及潜力，但量子计算提供的优势无法通过单独地使用尖端量子计算机来实现，而是还需要量子软件，这无疑将发挥重要作用。毫无疑问，“软件是无形的文字，它在我们的硬件中低声讲述可能性的故事”。

我们目前拥有的量子软件编程技术是以一种临时的方式实验性地提出的。因此，量子软件工程 (QSE)已成为一个新的研究领域，旨在通过应用从经典软件工程领域汲取的知识和经验教训来生产量子软件。这需要应用或改编现有的软件工程流程、方法、技术、实践和原则，或创建新的流程、方法、技术、实践和原则，以开发量子软件。在QSE领域，如何克服整个经典—量子信息系统分析和设计技术的不足是尚待解决的问题之一。本文的贡献在于试图填补这一空白。

到目前为止，大多数量子软件的编码都没有事先分析问题或设计模型。然而，需求工程和概念建模已经证明它们可以帮助解决这个问题。然而，目前有两个挑战阻碍了现有分析和设计技术在量子软件中的简单应用

• 量子软件建模量子计算基于量子力学的反直觉原理，包括叠加和纠缠等。因此，从现有和经典设计技术中吸取的教训不能简单地按原样应用，而是需要构思新的量子基础和特征。在这方面，量子软件目前仍在以手动、临时的方式进行编码。例如，虽然有一些众所周知的算法是通过数学形式主义在文献中定义的，但这些算法是针对特定的量子编程语言以多种方式手动编码的，没有任何事先设计或建模。
• 混合量子信息系统进一步采用量子信息系统并不需要完全取代经典信息系统。这两种技术将在所谓的“混合信息系统”中并行运行。这是因为使用量子软件解决简单问题没有意义，因为这些问题已经由经典计算机充分执行，而且成本更低。因此，经典软件在未来将充当驱动程序，协调对量子软件的请求。因此，经典量子信息系统必须一起分析和设计，这本身就构成了另一个重要挑战。

尽管存在这两个挑战，但现有经典软件工程方法和技术目前解决的许多问题仍然与我们在量子软件的设计和构建中发现的问题相同。例如，对软件的抽象描述是(i)讨论设计关注点的关键，(ii)在隐藏实现细节的同时，用高层次的概念表示建模系统的关键。在经典软件工程中使用最广泛的一种久经考验的解决方案是使用标准建模语言，例如统一建模语言 (UML) ，用于信息系统的分析和设计。该提议背后的主要假设是 UML 建模应该被视为对混合信息系统的分析和设计有用。

本文的主要贡献是提供了一个涵盖混合信息系统分析和设计的主要建模方面的量子 UML 概要文件。量子 UML 配置文件还涵盖结构和行为方面。特别是，它涉及用例、类、序列、活动和部署图。因此，量子和经典元素，以及它们之间的关系，都可以在一个集成设计中一起建模。

尽管在以前的提案中，UML已经通过各种领域特定语言(DSL)进行了扩展，但本提案通过一个概要文件的方式对其进行了扩展，该概要文件是为此目的而制定的标准机制。尽管与 DSL 相比，在 UML 配置文件中实现的量子扩展的表达能力有限，但这种可扩展性策略的主要含义是输出设计模型仍然符合 UML。因此，没有必要采用 UML 工具或为设计人员提供的培训，因为该表示法是众所周知的并且受到许多工具的支持。

本文的其余部分结构如下。第2节总结了当前的研究现状，第3节讨论了相关的学术工作。第4节介绍了主要的建议，即用UML图的一些例子来描述量子UML配置文件。第5节讨论了研究人员和从业人员的适用性和含义。第6节提供了一个应用程序示例，其中使用量子 UML配置文件构建了一个混合应用程序。最后，第7节给出结论和未来的工作。

目前工艺水平

本节提供了理解主要提案所必需的基本原则。首先，在2.1节中介绍量子计算；然后在2.2节中解释混合经典量子信息系统及其带来的挑战；最后，在2.3节中介绍了QSE这一新兴领域以及有待解决的问题。

量子计算原理

经典计算机以位（即 0 和 1）存储和处理信息，而量子计算机引入了量子位（量子位）的概念，它由一个概率函数建模，其中状态0和1同时具有一定的概率。这背后是量子力学的叠加原理。根据所涉及的量子计算技术，量子比特内部由偏振光子或电子自旋等进行管理。量子比特的实际状态只有在被测量后才能知道，尽管在那一刻量子比特会坍缩，因此它的状态无法再改变。量子比特的叠加性和概率性(以及其他违反直觉的原理，如纠缠或无克隆)使量子算法与经典计算中使用的算法非常不同。虽然经典算法是基于一系列命令式的步骤，以确定的方式操作数据，但量子算法的功能不同。量子软件基于概率函数来处理不确定性，并试图通过探索搜索空间来获得尽可能优的解。改变状态0和1概率的机制被称为“量子门”，其在各种量子位下的应用被组合在表示量子算法的量子电路中(或可以封装在新门中的部分)。

与经典版本相比，量子计算技术和量子编程语言存在各种差异：（i）除了非确定性和概率性控制之外，还缺乏可以管理传统控制的控制结构；(ii) 以组合方式对量子程序的推导有缺陷；(iii) 没有基于参数制定接口和签名，然后动态计算这些参数。这些差异与量子软件的内在本质有关，阻碍了众所周知的现有编程技术的应用。

混合量子信息系统

量子计算并不是一种一体化技术。由于量子计算的内在本质，它可能适合解决特定类型的问题，但不是每一个问题。对于某些问题，量子计算机受到与经典计算机相同的限制，而在其他时候，如果任务非常简单，则没有理由使用量子计算（一种更昂贵的技术）来解决经典计算机仍然可以执行的问题相当成功。因此，在未来，现代信息系统可能会集成经典和量子软件在“混合信息系统”中。这些系统支持一些使用经典编程语言实现的业务操作，这些语言执行对可以解决某些其他棘手问题的量子算法的调用。在这些混合系统中，经典软件在经典计算机（控制器或驱动器部分）中运行，而量子软件在通常位于云中的量子计算机（响应器部分）中运行。由于当今 NISQ（噪声中级量子）设备的计算能力在一定程度上仍然受到限制，因此可以在分布式量子计算架构中使用多个 NISQ 设备。混合信息系统使用经典控制器部分来支持两项重要任务：成本函数和优化 。成本函数是指将量子答案（基于量子比特的测量）转化为对现实世界问题有意义的答案的部分。在其他任务中，优化涉及估计和控制需要执行多少次量子部分才能获得可靠的答案，因为它基于概率搜索空间。根据[24]标准，混合信息系统在代码可移植性、工具集成、程序验证和工作流开发编排等方面存在障碍。对于其中一个障碍——代码的可移植性，已经有一些表示方法，如QIR (Quantum Intermediate Representation)等。

量子软件工程

量子软件和经典软件之间的根本差异，以及“量子计算机工具处于起步阶段”的事实，导致数学家、物理学家和计算机科学家通过遵循不同的、特别的方法来编写量子软件。 直到几年前，这种非系统的量子软件编码方式已经足够实验量子软件使用。然而，随着“工业”量子软件的出现及其在各个业务领域中越来越多的使用，人们越来越需要以更系统的方式生产量子软件，同时满足质量和其他预算和时间限制。因此，如今的量子软件不仅被编码，而且还在整个生命周期中被分析、设计、验证等。在 [ 30 ]中可以找到对当前对量子软件生命周期不同阶段的研究计划的调查。此外，应该注意的是，需要特定的量子软件工具来满足这些需求。正是在这种背景下，QSE 领域得到了发展，以技术、方法和实践的方式吸取了经典计算的经验教训。通过系统地应用以下原则，此类技术和方法已被证明可以应对众所周知的挑战，量子软件也面临这些挑战：工艺合理的抽象，保持清晰的关注点分离，争取平衡分布责任，始终追求简单。社区现在有机会在量子软件进一步出现并广泛普及之前将理论和技术落实到位。

QSE 领域的其他挑战包括对概念设计和软件模式、度量和质量保证、可靠测试和验证以及软件维护和演化的需求。本文关注其中一个挑战：量子软件的分析和设计，以及混合信息系统的分析和设计。

量子软件设计的相关工作

在 QSE 中，量子软件的分析和设计值得特别关注。软件分析处理问题域，即问题是什么。同时，设计与解域相关联，即问题应该如何解决。下面我们列出了一些涉及量子设计的举措。

迄今为止，大多数量子设计工作都是在量子算法的背景下进行的。例如，将布尔、可逆逻辑转换为基于量子门的量子电路的设计模式。同样，Wang 等人提出了代数函数可逆实现的 qFBE 方法。Wille等人还研究了用于不同量子体系结构的量子数据结构和算法映射的计算机辅助设计 (CAD) 方法和工具。Genç等人提供了一个通过虚拟现实环境设计量子算法的量子composer工具。所有这些方法都有助于编写量子软件，尽管作为设计解决方案，它们对整个混合信息系统的分析和设计没有帮助。

其他被称为映射技术的设计技术已经被开发出来，以使与硬件无关的量子电路适应量子计算机的特定限制。例如，Bandic 等人提出了一种基于空间探索策略结构化设计的映射技术。Zhou等人提出了一种基于模拟退火和启发式搜索的映射技术。与前面提到的一组设计方法类似，映射技术不能被视为高级设计解决方案，即那些管理抽象概念元素的解决方案。

还有其他方法和技术并不是真正的设计解决方案，但它们提供了一些抽象层来隐藏低级编码细节。例如，Thompson等人提供了一种非算法的机器学习方法，避免了将算法分解为量子门的需要，从而降低了不必要的复杂性。然而，这种方法受到对训练集的依赖的限制，根据定义，训练集会使该方法的结果产生偏差。另一种称为LIQUi的低代码设计方法，它为量子电路的优化、渲染或翻译提供了 DSL。Chancellor等人为量子和量子启发算法的用例提供决策框架。这项工作侧重于方法论部分，以确定用例是否应该或不应该作为量子软件实现。但是，它不支持对量子用例进行建模。

对于混合信息系统的设计，Weder 等人提议将 QuantMe作为命令式工作流建模语言的通用扩展。该提案实现了量子计算的集成，并且可以对经典应用程序和量子电路的编排进行建模。作者在Quantum4BPMN中应用了 BPMN（业务流程模型和表示法）的扩展，这是一种允许在混合信息系统的工作流设计中使用 BPMN 表示法的应用程序。这项工作的重点是混合信息系统中量子软件的执行工作流，但是抽象的概念设计不在该提案的范围内。Exman 和 Shmilovich还提出了一种适用于经典软件和量子软件的技术，该技术使用密度矩阵来定义正式的模块化设计。

其他作品涉及静态（结构）和动态（行为）部分的概念设计。例如，Ali 和 Yue提出了开发量子软件建模语言的指南，并提供了量子程序的概念模型以及基于状态机的建模示例。Perez-Delgado 和 Perez-Gonzalez提出了 Q-UML 扩展，用于将量子元素与经典元素一起建模。此扩展为类图和序列图提供了特定的图形符号，因此它被定义为完全独立的扩展。沿着类似的思路，Pérez-Castillo 等人提出了一个初步的 UML 扩展，用于基于符合 UML 的活动图定义量子电路。这项工作侧重于使用 UML 配置文件定义的量子电路建模，因此与现有的 UML 工具兼容。比较最后提到的这两个提议，[ 45 ]中的先前提议没有像当前的工作尝试那样涵盖除量子电路之外的其他 UML 图和概念设计。

量子 UML 配置文件

本节介绍了本文的主要贡献。首先，4.1节证明了选择量子UML配置文件而不是其他选择。然后，第4.2-4.6节详细解释了我们用来方便分析和设计混合信息系统的量子UML 配置文件。

建议的依据

混合信息系统的开发应该遵循完整的生命周期，即分析、设计、编码、测试等。管生命周期的确切性质是什么，量子软件必须在某个时候被设计出来。如相关工作部分所示，量子软件的开发，无论是孤立的还是在混合信息系统中，通常都是通过代码模块的直接实现来完成的。仅在一些初步提案中，在编码阶段之前使用了一些抽象规范。然而，迄今为止提出的建模方法并不完全符合 UML（因此还不能与现有工具一起使用），并且没有一种建模方法涵盖所有​​设计问题。

一般而言，软件设计用于集成体系结构、系统元素、接口和系统其他特征的定义，寻求使用一组原始组件并满足某些约束来实现目标。迄今为止，UML 已被证明是定义经典软件设计的有用方法。UML 可以帮助我们收集和分析软件需求，并以独立于技术和方法的方式将它们整合到程序设计中。

由于在经典软件设计中使用 UML 的好处已得到充分证明，我们建议在设计混合信息系统时也可以使用 UML。尽管可以使用其他建模语言来设计软件，但我们相信在量子软件工程中使用 UML 会带来几个好处：

• 不同的关注点UML 提供了不同类型的图，可以从不同的角度查看信息系统并表示不同的关注点。在混合信息系统建模时考虑这些不同的观点是很有用的，例如，将量子软件与经典软件区分开来。
• 设计验证这些不同的观点帮助量子软件工程师探索、交流和验证替代设计。如今，UML 的使用在工业中得到了高度扩展，并且对于非技术人员来说相当容易理解。对于混合信息系统，这很有用，因为软件工程师以外的专业人员可以理解和验证设计。
• 最佳实践UML 的使用本质上代表了最佳工程实践的集合，这些实践在大型复杂信息系统的建模中被证明是成功的。因此，这些实践也可以应用于量子/混合信息系统。这方面的一个例子是应用模型驱动工程 (MDE) 方法 来确保平台独立性和低代码生成技术的功能。
• 有组织的设计UML 建模使得将软件组织为自包含模块和组件的集合变得更加简单。结构化分解提高了代码的重用性、可扩展性、可维护性、稳健性等。事实上，这些功能现在是量子软件工程社区所需要的。
• 由于 UML 是一个 ISO/IEC 标准（由 OMG 首次发布）并被广泛采用，因此大多数现有的设计和建模工具已经支持它。事实上，UML 的目标之一是通过实现对象可视化建模工具的互操作性来推动行业发展。因此，量子软件建模可以集成到现有工具中。例如，初步用于量子软件的其他 DSL 和特定建模技术不能确保与现有工具的集成。因此，该 UML 特性确保了它的适用性。
• 学习曲线UML 已经被许多软件工程师使用，因此它可以扩展到量子领域，而不需要额外的培训。
• 软件现代化除了设计随后通过正向工程实现的目标混合系统之外，UML 模型还被用作逆向工程工具从源代码中获得的抽象表示的符号。因此，UML 用作将经典和量子软件迁移或现代化到混合信息系统 的一种手段。

然而，尽管有这些好处，UML 仍然需要进行调整，以捕获量子软件开发中涉及的所有新语义和构建元素。尽管本文的范围侧重于为量子软件扩展 UML，但可以探索如何在 UML 中表示量子计算机的其他基本属性（例如，叠加、纠缠等）。

本文提出的建议是对UML 进行扩展以使其适用于混合信息系统的尝试。在扩展 UML 时，我们首先应该记住 UML 是在 MOF（元对象工具）上定义的，它是一个元元模型。因此，这意味着 UML 是一个元模型，用于定义不同的 UML 模型，因此 UML 的扩展包括扩展 UML 元模型。需要记住，所有元模型定义都有抽象语法(描述元模型语言中的概念、它们的特征和相互关系)和具体语法(定义抽象元素所需的特定文本或图形表示法)。

考虑到这一点，可以通过遵循三种不同方法中的任何一种来扩展 UML。

• MOF 模型的新实例这种方法包括创建一个基于 MOF 的全新元模型。这个重量级扩展的结果是一种新的领域特定建模语言 (DSML)。
• 新的 UML 元模型的派生这种方法将新的元模型元素添加到现有元模型中。与第一种方法一样，它是一个不同的元模型，但至少它按原样考虑了原始 UML 元模型。
• UML 配置文件这是一种基于UML 内置扩展机制的轻量级扩展方法：UML Profiling。UML 配置文件是作为一组构造型、标记值和为某些现有 UML 元素定义的约束而创建的，这些元素会更改或添加语义，因此在实践中我们可以将构造型元素视为不同的元素。

一方面，很明显，前两种方法具有强大的表达能力，因为不需要符合 UML（特别是在新 MOF 实例的情况下）。另一方面，UML 概要文件的表达能力是有限的。但是，UML 概要文件的标准化和一致性更好，因为扩展完全符合 UML。对于将已定义的概要文件与现有的 UML 建模工具一起使用，此优势是一个关键方面。因此，我们相信这种方法将有助于最大限度地提高行业对 UML 扩展的采用。

此外，如果我们考虑 UML 扩展的未来发展，维护定义为 UML 概要文件的扩展会更容易，因为关联的建模工具不需要在每次更改后进行调整，就像 DSML 那样。事实上，DSML（方法 1 和 2）通常以超载和不精确的语言结束。这些优势使我们相信 UML 概要文件是为混合信息系统定义 UML 扩展的最佳选择。

量子 UML 配置文件被定义为一组构造型和适用于这些构造型的现有 UML 元素。UML 配置文件被定义为包含一组定义的构造型（可能有也可能没有特定图像）的包。然后必须将 UML 概要文件应用于特定模型。在应用配置文件时用于过滤哪些 UML 元素可用的特定属性是metamodelReference和metaclassReference。当将构造型应用于模型元素时，属性的值传统上称为标记值。

量子 UML 配置文件不涉及所有现有的 UML 元素，也不涉及整套 UML 图。相反，它侧重于对混合信息系统的设计有意义的特定图表。虽然 UML 模型由包、类和关联等元素组成，但可以在同一 UML 模型下构建多个 UML 图。UML 图添加了 UML 模型各部分的图形表示，例如，通过路径连接的节点。UML 考虑了十四种不同的图，分为结构图和行为图。提出的量子 UML 配置文件涵盖用例、类、序列、活动和部署图。

对于每种量子 UML 图，我们提供了两个图。首先，支持那种图表的 UML 配置文件的摘录。其次，相应类型的 UML 图作为示例来说明 UML 配置文件的使用。对于每个图的 UML 配置元模型，我们在左侧显示 UML 元模型的一部分，即现有的元类元素。浅灰色元素是非抽象实体，因此是可用于包含在 UML 图中的元素。在每个图的 UML 配置元模型中，我们在右侧提供了建议的 UML 配置元素以及从构造型到现有元类元素的向左侧箭头，这表明元类的属性使用各自的量子构造型进行了扩展。

整个 UML 配置文件已使用 Papyrus 定义，Papyrus 是一种工业级开源工具，允许按照 MDE 原则定义和管理 UML 配置文件。UML 配置文件的 Papyrus 项目文件，包括高分辨率的模型图像，可以在 [ 53 ] 访问。

用例图

用例图是一种行为图，用于定义信息系统应该做什么，即需求建模。此图中使用的关键概念是参与者、用例和主题（任何分类器）(参见图1)。每个主题代表应用用例所考虑的系统。用例可以通过两种关系相互关联：包括和扩展(参见图1)。

对于混合信息系统，我们在量子 UML 配置文件中提出了五种原型，它们能够应对经典量子软件中的以下建模挑战：

• 执行给定量子功能的量子环境的定义。尽管必须将混合信息系统视为一个整体，但应区分那些执行功能基于量子软件的用例。例如，一些用例可能被定型为≪Quantum≫。 应该注意的是，用例是在分析阶段使用的，它们的目的不是设计解决方案，而是简单地描述问题域。因此，在大多数企业管理信息系统中，在这一点上区分经典用例和量子用例没有意义。然而，还有其他系统的特定用例（例如，与物理学或量子化学中的量子模拟相关的用例）会自动限制量子软件的使用。因此，如果在分析阶段已经知道该决定，则应表示该信息，因为它对设计阶段很有价值。[ 40 ]中解决了确定量子用例的挑战。
• 表示特定用例执行的技术栈(软件和硬件)的量子环境应该被表示为一个actor元素，≪Quantum Computer≫。这些参与者应该通过≪Quantum≫的用例联系起来。
• 也可以表示从普通用例到基于量子的用例的量子请求的定义。如前所述，这取决于关于确切用例是什么的先验知识≪Quantum≫。该提案考虑了刻板印象≪Quantum Request≫可以在包含关系下应用。尽管此信息在分析阶段并不重要，但它可以帮助在以下设计图中跟踪此类量子请求。≪Quantum Request≫范式的语义是对量子软件编码的任何组件的调用，而量子软件必须在量子设备上运行。这并不意味着请求本身与任何内在的量子相关，只是对该请求的响应可能是量子的，因此需要某种转换。

图1：用例图的量子UML配置文件

图2提供了一个用例图的示例，该图使用了建议的构造型。图的左侧表示经典信息子系统的用例及其共同关系（包括和扩展）以及各种参与者。在经典软件部分，可能有一些功能需要量子算法来完成。示例中显示的用例没有任何构造型定义，但定义了与另一个≪Quantum≫用例。图2的右侧定义了≪Quantum≫基于（或支持）量子软件的用例。这些类型的用例永远不应该与人类参与者直接相关，因为它们通常是从充当驱动程序的经典用例中执行的。尽管如此，≪Quantum≫用例与代表量子环境的参与者相关≪Quantum Computer≫（见图2）。在这个例子中，只有一个量子环境。然而，可以考虑使用各种量子计算机来对复杂的混合信息系统进行建模。例如，让我们想象一个场景，在这个场景中，一些基于量子的用例应该在基于量子门的量子环境中开发，而另一个基于优化的功能将在量子退火系统中得到支持。

图2：混合信息系统的用例图示例

类图

图3总结了类图元素的 UML 元模型部分以及在可应用于某些元素的量子 UML 配置文件中定义的那些构造型。在设计混合信息系统时，类图可用于对经典软件进行建模(到目前为止一直是这样)，而对于量子软件，类图可用于以下附加目的：

• 首先，量子软件组件的设计使用支持功能的类和包进行建模，并允许将其开发为量子电路、算法或类似的工件。为此，≪Quantum≫构造型既可以用于整个包，也可以用于单个类。
• 管理对量子软件组件的调用的类驱动程序的定义。这由具有构造型的类元素表示≪Quantum Driver≫。
• 从经典软件包中的≪Quantum Driver≫类到≪Quantum≫类。类的量子调用和请求的设计。为这些调用建模是可选的，因此我们提出≪Quantum Request≫它可以与关联类和依赖项一起使用。首先，使用与关联类之间的≪Quantum Driver≫类和≪Quantum≫类允许将成本和优化函数链接到量子请求。第二，≪Quantum Request≫的依赖关系表示相同的调用，但以更简单的方式表示，即没有更多信息。此外，由于量子请求是由类中的操作触发的，因此≪Quantum Request≫构造型也可以与操作元素一起使用，以区别于驱动程序类中的其他辅助操作。

图3：类图的量子UML配置文件

图4显示了表示混合信息系统架构的类图示例。左侧为经典部分提供了传统的三层架构，即表示、业务逻辑和持久性包。右侧显示了经典量子部分。经典量子逻辑包包含量子驱动程序，该驱动程序对不同的量子算法执行量子请求，这些算法位于名为量子逻辑的包中。

在图4的例子中，量子请求使用与成本和优化函数关联的关联类建模。这仅表示在混合信息系统中设计请求的一种可能的设计模式，并不强制在所有情况下都遵循此示例。例如，量子请求可以在类或包之间用≪quantum Request≫这一范式来设计。此外，在某些设计中，可能对量子请求不感兴趣，因此可以忽略。

关于量子软件组件，结构图没有显示动态行为的细节，而是用行为图表示。因此，量子算法简单地由黑盒元素表示为类。然而，一些行为图可能显示与类图中展示的分类器的行为的关系。因此，可以根据建议的 UML 配置文件(参见4.5节)使用活动图对相应的量子电路进行建模，这可以在图表概述元素中引用，而且≪refine≫这完全是对≪quantum≫类的依赖，这完全是≪quantum≫的原理。

图4：使用量子UML配置文件的混合信息系统的类图示例

序列图

序列图是一种交互 UML 图，它允许人们对交换的消息序列进行建模，以及它们在生命线上的相应出现规范(参见图5)。这些图同时捕获两个方面，对象和时间维度。序列图可用于分析和设计阶段。这两种序列图都可用于在混合信息系统的开发和现代化过程中对一些其他方面进行建模。在分析阶段使用的那些与用于用例场景建模的量子 UML 配置文件(参见第4.2节)所引入的元素相关，此外，设计序列图用于描述类图的动态行为(参见第4.3节)。本节的重点是设计序列图。

图5：序列图的量子UML配置文件

图6显示了一个序列图的例子，它使用量子 UML 概要文件来设计混合信息系统。左边的前三条生命线说明了图4中之前定义的三层架构中对象之间的共同交互。

为类定义的原型也用于量子软件部分的生命线上(图6右侧)。因此，≪Quantum Driver≫生命线负责创建一个新的实例对象≪Quantum Driver≫，这反过来又创建了类优化器和成本函数的实例，用于管理≪Quantum≫组件的特定请求。由于可以根据优化器和成本函数实体向量子算法发出多个量子请求，因此可以在图中的该部分添加一个循环片段。应该注意的是≪Quantum Driver≫这一模版也被用在这张图中，用来定义经典软件和量子软件之间的信息。此外，这幅图中使用≪Quantum Reply≫这一范式，表示量子算法的答案是由≪Quantum≫组件发出的。在量子请求和回复循环之后，应用成本函数将量子答案转换为有用的经典答案。然后通过所有相关的生命线将此信息发送给参与者作为答复(见图6)。

图6：混合信息系统设计顺序图实例

活动图

活动图除了通常用于设计经典软件外，还可以用于模拟量子电路。普通活动图可以显示动作之间的控制流，即这些图可以描述并发、分支、控制和对象流等(参见图7)。

图7：活动图的量子UML配置文件

图8提供了一个基于 [ 45 ] 的全加器算法的 UML 活动图示例。量子算法由具有构造型的单个复合活动表示≪Quantum Circuit≫。因此，整个电路在此活动中定义，复合活动可以在其他电路中重复使用，这在量子编程中经常发生。各种活动分区(图形上表示为水平泳道)可以在父活动中使用≪Qubit≫这一范式进行定义。该电路具有与算法中使用的不同量子位一样多的活动分区。因此，电路中应用的所有不同量子门都表示为动作元素，并根据应用或控制门的量子位放置在各自的泳道中。一方面，普通的量子门（如H、Y、Z等）表示为调用操作动作加上≪Quantum Gate≫这一范式。另一方面，条件门由多个动作元素表示。控制量子位由具有构造型的发送信号动作元素表示≪Controlled Qubit≫，而应用的门由对应元素表示，接受事件操作，加上≪Quantum Gate≫范式(图7)。此外，为了添加有关控制量子位之间关系的语义，在涉及的各种动作元素之间建立了各种 UML 约束元素。除了这些核心元素外，特殊操作，如量子比特测量和量子比特重置，用值规范动作要素及其对应的范式来表示，≪Measure≫和≪Reset≫。

图8：量子全加器算法的活动图示例

量子 UML 配置文件建议使用这种图以与现有符号类似的方式表示量子电路。一方面，它提供了两个好处：量子电路的设计符合 UML（因此它们可以与其他 UML 元素和整个图表集成），并且现有的 UML 建模工具支持这种表示法。另一方面，为此目的使用活动图 i) 可能会影响此类 UML 图的主要用途；ii) 活动图的元素不支持新的量子门和特定符号。因此，我们认为最好的长期选择是，在 UML 标准的下一次修订中，包括一种新的图表来支持量子电路的建模。另外，还有其他基于UML的建议来建模量子程序的状态叠加和概率性质，例如通过使用状态机[44]。这些提案也与使用提案概要文件的UML模型兼容。

部署图

部署图是一种结构图，用于对系统的执行体系结构进行建模以及将软件工件分配给系统元素（节点）。这些图表捕获系统的逻辑和/或物理组件与分配给它们的信息技术工件之间的关系(参见图9)。

部署图的目的是规划系统的体系结构并记录软件组件的部署。在混合信息系统的设计环境中，部署图可用于以下目的：

• 展示运行时经典量子系统的结构。
• 捕获将用于实现系统的硬件，即≪Quantum≫应用于不同节点的原型，以及部署在内部的量子组件。
• 充当硬件不同节点之间的链接，即充当驱动程序的经典服务器与执行命令的量子计算机之间的链接≪Quantum≫组件。
• 对物理硬件元素之间的通信路径进行建模。例如，部署图可以捕获从经典软件工件到量子软件工件的量子请求（参见图9中用于 Artifact 元素的≪Quantum≫范式）。

图9：用于部署图的量子UML配置文件

图10显示了混合信息系统的原型部署图示例。右侧定义了量子端，其中与量子算法相对应的工件部署在用于部署图的量子UML概要文件节点。需要注意的是，可以对量子驱动组件和量子组件之间的特定接口进行建模。这些接口可以被建模为类，可以重用之前描述的≪Quantum Request≫范式(参见4.3节)。除了那些构造型之外，图10中的部署图还使用了 UML 中已经定义的其他普通构造型（例如，≪device≫、≪executionEnvironment≫和≪call≫)。

图10：混合信息系统的部署图示例

讨论

本文所提出的量子 UML 配置文件已根据 UML 图的种类进行了传播。然而，UML 配置文件中包含的大多数构造型都适用于各种元素(见表1)。例如，(见表1)构造型应用于四 (4) 个不同图表中涉及的七 (7) 个不同元素（即，构造型与特定 UML 元素而不是图表类型相关联）。根据 UML 标准，可以在不同的图中使用各种元素。因此，量子 UML 配置文件也是如此，这意味着除了本文中解释的那些之外，一些构造型还可以应用于其他图表。例如，包元素（可以构造为≪Quantum≫) 可以在大多数 UML 图中使用。关于结构图，对象图可以使用所有三 (3) 个可应用于类元素的构造型。以类似的方式，组件图也可以使用≪Quantum≫应用于组件元素的构造型。关于行为图，另一个例子是通信图，它在某种程度上等同于序列图，尽管重点是生命线元素的结构组织而不是时间线定义。通信图可以包括为以下元素定义的所有构造型：参与者、生命线、消息和泳道。

表 1 UML 配置文件和相关元素中定义的构造型摘要

关于 UML 的使用，研究和实践者团体是相当不同的。一方面，研究人员通常将重点放在深度大于广度的特殊用途解决方案的正式建模符号上。另一方面，实践者往往将实用性置于严谨性之上，以寻找可以在开发项目中提供系统架构作为全局图景的通用解决方案，即他们注重广度而非深度。

考虑到这一点，研究界可以使用 Quantum UML 配置文件作为建立新研究问题和开发相关解决方案的基础。例如，正如我们之前所说，UML 提供了不同类型的图表，用于从不同的角度查看信息并表示不同关注点的视图。研究界可能想知道，除了 UML 提供的用于指定“经典”系统的视角之外，量子系统是否还需要进一步的视角（观点）。算法通常在经典 UML 模型中被丢弃，因为它包含底层细节。然而，这部分对于量子软件至关重要。量子算法必须在特殊规则下定义，因此这方面在 UML 中可能有特定的视图。与此相关，已经提议将量子电路建模为 UML 活动图。尽管如此，人们可能会认为这种表示法没有提供任何关于现有非 UML 表示法的抽象。尽管如此，我们相信这允许将量子电路的信息与整个 UML 模型中的其他 UML 元素集成。或者，在未来，可以提出一种新的 UML 图来用新的量子软件元素来表示这一点：量子位、门等。研究界可能提出的其他相关问题是传统的软件工程方法是否同样有效对于量子系统。也许需要新的软件工程方法，因此也需要新的符号(如UML图)。在这方面，应该研究混合信息系统的设计方法。因此，在量子UML概要文件中考虑的每一种图都应该被定义为根据软件设计方法学的一组活动或步骤的结果。

对于实践者来说，主要的意义是他们可以在他们的建模工具中导入量子 UML 配置文件，并可以开始定义必要的分析和设计模型，以捕获混合信息系统的量子方面。这也意味着他们不需要学习新的建模语言或工具。此外，分析问题域和为目标混合信息系统定义概念架构所需的工作在某些方面仍然可以独立于 UML 模型的编码任务，这可以主要由其他类型的专业人员来处理。

应用示例

本节提供了一个使用所提出的量子 UML 配置文件的示例，以分析其在设计和构建混合软件系统方面的实用性和适用性。目标系统是一个金融web应用程序，用于评估看涨期权的定价收益。第6.1节介绍了问题的定义及其背景。然后，通过用例图的分析模型在章节6.2中展示，而通过类图的设计模型在章节6.3中描述。两种模型均使用Papyrus工具进行建模，整个建模方案在[54]中实现。最后，第6.4节展示了一个功能性的web应用程序，它遵循[55]中的设计实现。

问题定义和背景

本示例的灵感来自于 QisKit 金融库中提供的示例，该示例用于估算欧洲看涨期权定价的收益 。在金融服务中，“看涨期权”是一种期权合约，它赋予了在到期日之前或到期日以预定价格购买标的资产的权利，但没有义务。与美国模式相比，欧洲模式只能在到期时行使。有了这个财务模型，问题就是估计收益，即期权定价和风险分析。这个问题并非微不足道，经典计算机无法解决，并且已经通过量子振幅估计算法解决了。

QisKit 提供的示例展示了一个简单的交互式笔记本，其中经典和量子部分被合并，许多参数和信息是静态的。这是意料之中的，因为这是一个重点展示量子算法在解决金融问题上的应用的例子。我们在示例中的建议是设计和开发功能性 Web 应用程序（作为混合软件系统），供经纪人和交易员用来估算看涨期权的收益。因此，Web 应用程序可以集成一些经典部分，例如，通过一些财务参数来定义看涨期权，以及固定目标（如定价点）等。因此，应用程序能够通过以下方式估算收益对前面提到的量子算法的要求。

分析模型

分析模型由一个用例图(见图11)组成，定义了混合软件系统的主要使用场景。该系统的主要功能是估算给定看涨期权的收益（参见用例“计算收益”）。这个用例包括（原型化为≪QuantumRequest≫) 另一个执行量子算法的用例（用≪Quantum≫) 来估计收益。此外，还有两个用例“定义欧式看涨期权”和“定义定价目标”。这些用例分别用于定义财务模型和定价参数以计算收益。该系统可以包括与问题领域相关的其他经典功能，但是它已尽可能简单以用作示例。

最后，应该注意到图11右侧的actor，它代表用于执行量子算法的量子计算机。由于这是一个应用程序示例，因此它使用了QisKit的内置模拟器。

图11：欧洲看涨期权定价应用程序的量子UML配置的用例图

设计模型

考虑到用例图中的主要功能，类图被建模为设计模型中的主要工件(参见图12)。该图遵循之前在4.3节中提出的相同架构。首先，表示包根据三个主要用例考虑了与代理与系统交互直接相关的三种形式(参见图11)。

一方面，有两种与经典用例相关的形式，它们依赖于“businesslogic.controllers”包中的“EuropeanController”。该控制器管理两个实体，“EuropeanCallProblem”和“EuropeanCallObjective”，分别表示与财务模型和定价参数相关的两个案例研究的信息，即目标函数。

另一方面，“EvaluatePayoffForm”（与基于量子的用例相关联）依赖于“EuropeanCallDriver”（与≪量子驱动器≫). 该类与类“EuropeanCallQuantumRequest”和“EuropeanCallEstimation”一起位于“classicalquantumlogic”包中。第一类是定型的≪量子请求≫并管理对目标量子计算执行远程调用所需的信息（例如，量子计算机端点、发射次数和特定算法的其他参数）。其次，“EuropeanCallEstimation”类表示将量子算法的回复转换为有价值/可理解的经典答案的成本函数类，即本例中的收益估计。

“EuropeanCallDriver”类具有属性“QAEAlgorithm”，在 UML 图中表示为与类“QuantumAmplitudeEstimationAlgorithm”的关联(参见图12)。这个类位于` quantumlogic. js `文件中。算法的包装和两者都用≪Quantum≫这个原型指出，这些软件制品正在编码或支持一些量子算法。其中，该类是基于Grover算法的编码的量子幅度估计算法的编码。这个类针对之前介绍的实体类定义了一个问题和客观属性，因为这个量子算法是通用定义的，并且传出算法是根据这些参数动态构建的。

图12：定价欧洲看涨期权应用程序的带有量子UML配置文件的类图

实施模型

为了验证之前介绍的 UML 分析和设计模型，这些已用于编写具有上述功能的 Web 应用程序。因此，我们将 Python 与 QisKit 和 Flask 分别用作量子和 Web 开发框架。图13显示了三个可用主要表单中的两个的快照。左侧快照是经纪人可以在其中定义定价参数的页面，即定义给定看涨期权问题的目标。图13的右侧显示了收益估计的结果，以及由此产生的量子算法。

图13：欧洲看涨期权应用的定价快照

结论

本文针对目前混合信息系统分析和设计技术缺乏的问题，提出了一种量子UML配置文件。量子UML配置文件由一组可以应用于20个标准UML元素中的12个构造型组成。量子 UML 配置文件的使用已通过至少五种图表进行了演示：用例、类、序列、活动和部署。我们相信此 UML 配置文件不仅对设计混合信息系统有价值，而且对通过用例图和序列图进行的先前分析也很有用。此外，量子 UML 配置文件可用于对混合信息系统的静态（结构）和动态（行为）观点进行建模。主要含义是量子 UML 配置文件，及其与各种 UML 图一起使用的示例，为经典​​量子信息系统的开发提供了一套设计指南。该提案特别建议应如何管理经典软件和量子软件之间的关系，以及如何在抽象设计中对这些关系进行建模。

量子 UML 配置文件为混合信息系统的设计提供了一种方法。然而，对于分析和设计这样的经典量子系统的方法，还没有人说过。未来的研究需要朝这个方向进行。尽管已经有一些基于 UML 的方法论用于经典信息系统的建模，例如 Rational Unified Process，设计混合信息系统需要考虑具体的方法。除了方法论部分，未来要分析的另一个有趣的点是传出的 UML 模型如何被能够自动生成部分代码的低代码工具使用。尽管已经存在用于生成经典软件的此类工具，但我们认为从 UML 模型生成量子代码是一个重要的问题，应该进一步研究。最后，要探索的最后一点是如何在UML中建模量子计算的基本属性(除了那些与量子软件相关的更高抽象级别)。

原文链接：https://link.springer.com/article/10.1007/s00607-022-01091-4

---煤油灯科技victorlamp.com翻译整理---