This section presents the main contribution of the paper. First, Sect. 4.1 justifies the selection of the quantum UML profiles against other alternatives. Then, Sects. 4.2–4.6 explain in detail the quantum UML profile which we have used for facilitating the analysis and design of hybrid information systems.
Rationale of the proposal
The development of hybrid information systems should follow a complete life cycle, i.e., analysis, design, coding, testing, and so forth [15, 29]. Irrespective of the precise nature of the life cycle is, the quantum software has to be designed at some point. As shown in the section dealing with related work, the development of quantum software, whether isolated or within hybrid information systems, has usually been accomplished through the direct implementation of code modules. Only in some preliminary proposals, some abstract specifications have been used prior to the coding stage [17, 45]. However, the modelling methods that have been proposed up to now are not fully UML-compliant (and therefore are not ready to be used with the existing tools), and none of the modelling methods yet cover all of the design concerns.
In general terms, software design serves to integrate definitions for the architecture, system elements, interfaces and other characteristics of a system , seeking to accomplish goals using a set of primitive components and meeting certain constraints . UML has thus far proven to be a useful means to define classical software designs . UML can help us by gathering and analysing software requirements and incorporating them into a program design in a technology- and methodology-independent manner .
Due to the well-proven benefits of using UML in classical software design, we suggest it is also possible to use UML in designing hybrid information systems. Although other modelling languages may be used to design software, we believe that the use of UML in quantum software engineering delivers several benefits:
Different concern viewpoints UML provides different kinds of diagrams with which to look at information systems from varying perspectives and to represent the views of different concerns. It is useful to take into account these different viewpoints for modelling hybrid information systems, e.g., to distinguish quantum software pieces from classical counterparts.
Design validation These various perspectives help quantum software engineers to explore, communicate and validate alternative designs. The use of UML is highly extended in industry these days and is reasonably easy to understand for non-technical staff. For hybrid information systems, this is useful since professionals apart from software engineers can understand and validate designs.
Best practices The use of UML inherently represents a collection of the best engineering practices that have proved successful in the modelling of large complex information systems. These practices could consequently be applied in quantum/hybrid information systems as well. One example of this is the application of the Model-Driven Engineering (MDE) approach  to ensure platform independence and the functioning of low-code, generative techniques.
Organised design UML modelling makes it simpler to organise software as a collection of self-contained modules and components. The structured decomposition improves the reuse of code, scalability, maintainability, robustness, among others. In fact, these features are now demanded by the quantum software engineering community .
Tooling Since UML is an ISO/IEC standard (firstly released by OMG) and is widely adopted, most of the existing design and modelling tools already support it. In fact, one of the goals for UML is to advance the state of industry by enabling object visual modelling tool interoperability . As a result of this, quantum software modelling could be integrated into the existing tools. For example, other DSL and specific modelling techniques preliminary used for quantum software do not ensure that integration with the existing tools. As a result, this UML feature ensures its applicability.
Learning curve UML is already used by many software engineers, so its extension into quantum fields could be learned without any great need for additional training.
Software modernisation In addition to the design of target hybrid systems that are then implemented by forward engineering, UML models are also used as a notation for the abstract representations obtained from the source code by reverse engineering tools. Thus, UML serves as a means to migrate or modernise classical and quantum software towards hybrid information systems .
Despite such benefits, however, UML still needs to be adapted in order to capture all the new semantics and building elements involved in the development of quantum software, as has been shown in some of the previous work undertaken (cf. Sect. 3). Although the scope of the paper focuses on extending UML for quantum software, it could be explored how to represent in UML other fundamental properties of quantum computers (e.g., superposition, entanglement, etc.).
The proposal made in this paper is an attempt to extend UML to adapt it for hybrid information systems. When extending UML, we first should remember that UML is defined on an MOF (Meta-Object Facility) , which is a meta-metamodel. This therefore means that UML is a metamodel which is used to define different UML models, and the extension of UML consequently consists of extending the UML metamodel. It is necessary to bear in mind that all the metamodel definitions have both an abstract syntax (that describes the concepts, their characteristics, and interrelationships in the metamodel language) and a concrete syntax (that defines the specific textual or graphical notations required for the abstract elements).
Taking this into account, it is possible to extend UML by following any one of three different approaches [18, 52].
A new instance of the MOF model This approach consists of creating a completely new metamodel based on MOF. The result of this heavyweight extension is a new Domain-Specific Modelling Language (DSML).
Derivation of a new UML metamodel This approach adds new metamodel elements to the existing one. As occurs with the first approach, it is a different metamodel, but at least it considers the original UML metamodel as is.
UML profile This is a lightweight extension approach that is based on the UML built-in extension mechanism: UML Profiling. UML profiles are created as a set of stereotypes, tagged values and constraints defined for some of the existing UML elements, which changes or adds semantics, so in practice we can consider stereotyped elements as different ones.
On the one hand, it is clear that the first two approaches have a powerful expressiveness, since conformity with UML is not required (particularly in the case of new MOF instances). On the other hand, the expressiveness of the UML profiles is limited. However, standardisation and conformance are better for UML profiles, since the extension is fully compliant with UML. This advantage is a key aspect as regards the use of the defined profile with existing UML modelling tools. Consequently, we believe this approach will serve to maximise the adoption of the UML extension by industry.
Moreover, if we consider the future evolution of the UML extension, it is easier to maintain extensions that have been defined as UML profiles since the associated modelling tools do not need to be adjusted after each change, as occurs with a DSML. In fact, DSMLs (approaches 1 and 2) usually end up with an overloaded and imprecise language. These advantages lead us to believe that the UML profile is the best option to define the UML extension for hybrid information systems.
The quantum UML profile is defined as a set of stereotypes and existing UML elements to which such stereotypes apply. A UML profile is defined as a package containing a set of defined stereotypes (that may or may not have a specific image). The UML profile must then be applied to a certain model. The particular attributes used to filter which UML elements are available when the profile is applied are metamodelReference and metaclassReference. When a stereotype is applied to a model element, the values of the properties are traditionally referred to as tagged values.
The quantum UML profile does not address all the existing UML elements nor the whole set of UML diagrams. It focuses instead on the particular diagrams that make sense for the design of hybrid information systems. While a UML model consists of elements such as packages, classes, and associations, several UML diagrams may be built under the same UML model. UML diagrams add graphical representations of the parts of a UML model, e.g., nodes connected by paths. UML considers fourteen different kinds of diagrams divided into structure and behaviour diagrams. The proposed quantum UML profile covers the use cases, class, sequence, activity, and deployment diagrams.
For each kind of quantum UML diagram, explained in the following sections, we provide two figures. First, the excerpt of the UML profile that supports that kind of diagram. Second, a UML diagram of the respective type that serves as an example to illustrate the use of the UML profile. For the UML profile metamodel of each diagram, we present at the left-hand side the part of the UML metamodel as is, i.e., the existing metaclass elements. Light grey elements are the non-abstract entities and are, therefore, the elements available to be included in the UML diagram. In the UML profile metamodel of each diagram, we provide in the right-hand side the UML profile elements proposed plus the leftwards arrows from stereotypes to the existing metaclass elements, which indicate that the properties of a metaclass are extended using the respective quantum stereotype.
The whole UML Profile has been defined with Papyrus, an industrial-grade open-source tool that allow to define and manage UML profiles following the MDE principles. The Papyrus project files for the UML profile, including model images with high resolution, can be accessed at .
Use case diagrams
A use case diagram is a type of behaviour diagram for defining what the information system is supposed to do, i.e., the requirement modelling . The key concepts used in this diagram are actor, use case, and subjects (any classifier) (see Fig. 1). Each subject represents a system under consideration to which the use case applies. Use cases can be related with each other through two relationships: include and extend (see Fig. 1).
For hybrid information systems we propose five stereotypes in the quantum UML profile (see Fig. 1) that are capable of meeting the following modelling challenges in classical-quantum software:
The definition of quantum environments where a given quantum functionality is executed. Although the hybrid information systems must be seen as a whole, a distinction should be made as to those use cases where the functionality performed is based on quantum software. For example, some uses cases might be stereotyped with \(\ll \)Quantum\(\gg \). It should be noticed that use cases are employed at the analysis stage and their purpose is not to design the solution but simply to depict the problem domain. Hence, in most of the enterprise, management information systems, it does not make sense to distinguish classical and quantum use cases in this point. Nevertheless, there are other systems in which specific use cases (e.g., those related to quantum simulations in physics or quantum chemistry) that automatically constrain the usage of quantum software. As a result, if this decision is already known at the analysis stage, this information should be represented since it will be valuable for the design stage. The challenge of determining quantum use cases is addressed in .
The quantum environments that represent the technology stack (software and hardware) where a specific use case is performed should be denoted as an actor element with the \(\ll \)Quantum Computer\(\gg \) stereotype. These actors should be connected through associations with the \(\ll \)Quantum\(\gg \) use cases.
The definition of quantum requests from ordinary use cases to quantum-based use cases could be denoted as well. As explained before, this depends on the prior knowledge about exactly what use cases are \(\ll \)Quantum\(\gg \). The proposal considers the stereotype \(\ll \)Quantum Request\(\gg \) that can be applied under include relationships. Although this information is not crucial at the analysis stage, it can help to trace such quantum requests in the following design diagrams. The semantics of the \(\ll \)Quantum Request\(\gg \) stereotype is a call to any component encoded as quantum software, which must run on a quantum device. This does not mean that the request itself is related to anything inherently quantum, beyond the fact that the response to that request could be quantum and thus need some kind of transformation.
Figure 2 provides an example of a use case diagram that employs the proposed stereotypes. The left-hand side of the diagram represents the use cases of the classical information subsystem with their common relationships (include and extend) as well as various actors. In the classical software part, there could be some functionality that requires the accomplishment of quantum algorithms. The use case shown in the example is defined without any stereotype but defines an include relationship with another \(\ll \)Quantum\(\gg \) use case. The right-hand side of Fig. 2 defines the \(\ll \)Quantum\(\gg \) use cases based on (or supported by) quantum software. These kinds of use cases should never be directly related to human actors, since they are typically performed from classical use cases that work as a driver. Nonetheless, the \(\ll \)Quantum\(\gg \) use cases are related with actors that represent quantum environments stereotyped with \(\ll \)Quantum Computer\(\gg \) (see Fig. 2). In this example, there is only one quantum environment. However, various quantum computers could be considered for the modelling of complex hybrid information systems. For instance, let us imagine a scenario in which some quantum-based use cases are supposed to be developed in a quantum environment based on quantum gates, while another optimisation-based functionality is to be supported in quantum annealing systems.
Figure 3 summarises the UML metamodel part for class diagram elements as well as for those stereotypes defined in the quantum UML profile that can be applied to certain elements. In designing hybrid information systems, a class diagram could be used for modelling classical software (as has been the case up to now), while for quantum software, class diagrams could be used with the following additional purposes:
First, the design of quantum software components is modelled with classes and packages that will support functionality and allow it to be developed as quantum circuits, algorithms, or similar artifacts. For this purpose, the \(\ll \)Quantum\(\gg \) stereotype can be used with both whole packages and individual classes.
The definition of the class drivers that manage invocations to the quantum software components. This is represented by a class element with the stereotype \(\ll \)Quantum Driver\(\gg \).
Design of quantum calls or requests from the \(\ll \)Quantum Driver\(\gg \) classes in the classical software packages to \(\ll \)Quantum\(\gg \) classes. Modelling these calls is optional and we therefore propose the stereotype \(\ll \)Quantum Request\(\gg \) which can be used with both association classes and dependencies. First, the use with an association class between the \(\ll \)Quantum Driver\(\gg \) class and the \(\ll \)Quantum\(\gg \) class allows one to link cost and optimisation functions to the quantum request. Second, a \(\ll \)Quantum Request\(\gg \) dependency represents the same call but in a more simplistic way, i.e., without further information. Moreover, since the quantum request is triggered from an operation in the class, the \(\ll \)Quantum Request\(\gg \) stereotype can be also used with operation elements to distinguish it from other auxiliary operations in the driver class.
Figure 4 shows an example of a class diagram that represents the architecture of a hybrid information system. The left-hand side provides the traditional three-layer architecture for the classical part, i.e., presentation, business logic, and persistency packages. The right-hand side shows the classical-quantum part. The classical-quantum logic package contains the quantum driver that performs quantum requests to different quantum algorithms which are placed in a package named quantum logic.
In the example of Fig. 4, the quantum request is modelled with an association class that is associated with the cost and optimisation functions. This represents only one possible design pattern for designing requests in hybrid information systems and it is not mandatory to follow this example in all cases. For instance, the quantum requests could be designed with a dependency, with the \(\ll \)Quantum Request\(\gg \) stereotype, between classes or packages. Furthermore, in some designs, quantum requests might not be of interest and so could be omitted.
Regarding the quantum software components, the structure diagrams do not show the details of dynamic behaviour, which are instead represented by behavioural diagrams. Hence, quantum algorithms are simply represented, by black box elements, as classes. However, some behaviour diagrams may show relationships to the behaviours of the classifiers exhibited in the class diagrams. The respective quantum circuits can therefore be modelled with activity diagrams according to the proposed UML profile (cf. Sect. 4.5), which could be referenced in diagram overview elements plus a \(\ll \)refine\(\gg \) dependency to the \(\ll \)Quantum\(\gg \) class.
Sequence diagrams are interaction UML diagrams that allow one to model the sequence of messages that are exchanged, along with their corresponding occurrence specifications on the lifelines (see Fig. 5). These diagrams simultaneously capture two aspects, the object and the time dimension. Sequence diagrams can be used in both analysis and design stages. Both kinds of sequence diagrams are useful for modelling some additional aspects during the development and modernisation of hybrid information systems. Those used in the analysis stage are related to the elements introduced by the quantum UML profile for use cases (cf. Sect. 4.2) for modelling use case scenarios. Additionally, design sequence diagrams are used for depicting dynamic behaviour regarding class diagrams (cf. Sect. 4.3). This section focuses on the design sequence diagrams.
Figure 6 shows an example of a sequence diagram that employs the quantum UML profile for the design of hybrid information systems. The first three lifelines to the left illustrate a common interaction between objects in the three-tier architecture previously defined in Fig. 4.
The same stereotypes defined for classes are also used for lifelines for the quantum software part (the right-hand side of Fig. 6). Thus, the \(\ll \)Quantum Driver\(\gg \) lifeline is responsible for creating a new instance object of \(\ll \)Quantum Request\(\gg \), which in turn creates instances of the classes Optimizer and CostFunction for managing specific requests to \(\ll \)Quantum\(\gg \) components. Since multiple quantum requests could be made to the quantum algorithm in accordance with the optimiser and cost function entities, a loop fragment may be added in that part of the diagram. It should be noticed that the \(\ll \)Quantum Request\(\gg \) stereotype is also used in this diagram to define what the messages are between classical and quantum software. Additionally, the \(\ll \)Quantum Reply\(\gg \) stereotype is used in this diagram to denote that the quantum algorithm answer has been sent by the \(\ll \)Quantum\(\gg \) component. After the loop of quantum request and reply, the cost function is applied to translate the quantum answers to a useful classical answer. This information is then sent in reply to the actor through all the involved lifelines (see Fig. 6).
Apart from their ordinary use for designing classical software, activity diagrams can be used for modelling quantum circuits, as was suggested in . Ordinary activity diagrams can show the control flow between actions, i.e., these diagrams can depict concurrency, branch, control, and object flow, etc. (see Fig. 7).
Figure 8 provides an example of a UML activity diagram for a full adder algorithm based on . Quantum algorithms are represented by a single compound activity with the stereotype \(\ll \)Quantum Circuit\(\gg \). The entire circuit is, therefore, defined in this activity, and the compound activity can be reused in other circuits, as often occurs in quantum programming. The various activity partitions (graphically represented as horizontal swim lanes) can be defined in the parent activity by employing the \(\ll \)Qubit\(\gg \) stereotype. The circuit has as many activity partitions as different qubits used in the algorithm. All the different quantum gates applied in the circuits are, therefore, represented as action elements and are placed in their respective swim lanes, according to the qubit under which the gate is applied or controlled. On the one hand, ordinary quantum gates (such as H, Y, Z, etc.) are represented as call operation actions plus the \(\ll \)Quantum Gate\(\gg \) stereotype. On the other hand, conditional gates are represented by multiple action elements. The control qubits are represented by send signal action elements with the stereotype \(\ll \)Controlled Qubit\(\gg \), while the gate applied is represented by the counterpart element, accept event action, plus the \(\ll \)Quantum Gate\(\gg \) stereotype (see Fig. 7). Additionally, to add the semantic concerning the relationships between the control qubits, various UML constraint elements are established between the various action elements involved . Apart from these core elements, special operations, such as qubit measuring and qubit resetting, are represented by value specification action elements and their respective stereotypes, \(\ll \)Measure\(\gg \) and \(\ll \)Reset\(\gg \).
The quantum UML profile proposes the use of this kind of diagrams to represent quantum circuits in a similar way to the existing notations. On the one hand, it provides two benefits: the design of quantum circuits is UML-compliant (they can therefore be integrated with other UML elements and with whole diagrams) and this notation is supported for the existing UML modelling tools. On the other hand, the use of activity diagrams for this purpose i) can detract from the primary use of such UML diagrams; and ii) new quantum gates and specific notation cannot be supported by the activity diagrams’ elements. As a result, we believe that the best long-term option is, at the next revision of the UML standard, to include a new kind of diagram to support the modelling of quantum circuits. Alternatively, there are other UML-based proposals for modelling the state superposition and probabilistic nature of quantum programs, for example by using state machines . These proposals are also compatible with UML models using the proposed profile.
A deployment diagram is a kind of structure diagram used in modelling the execution architecture of systems and the assignment of software artifacts to system elements (nodes). These diagrams capture relationships between logical and/or physical components of systems and the information technology artifacts assigned to them (see Fig. 9).
The purpose of deployment diagrams is to plan the architecture of a system and to document the deployment of software components. In the context of the design of hybrid information systems, deployment diagrams can be used with the following purposes:
To show the structure of the run-time classical-quantum system.
To capture the hardware that will be used to implement the system, i.e., the \(\ll \)Quantum\(\gg \) stereotype applied to different nodes, as well as the quantum components deployed inside.
To act as a link between different nodes of the hardware, i.e., between the classical server acting as a driver and the quantum computer that executes the \(\ll \)Quantum\(\gg \) components.
To model the communication paths between physical hardware elements. For example, deployment diagrams can capture the quantum requests made from classical to quantum software artifacts (see the \(\ll \)Quantum\(\gg \) stereotype in Fig. 9 as applied to the Artifact element).
Figure 10 shows an example of an archetype deployment diagram for hybrid information systems. The right-hand side defines the quantum side where the artifacts that correspond to the quantum algorithm are deployed in a \(\ll \)Quantum\(\gg \) node. It should be noted that specific interfaces between the Quantum Driver component and the Quantum Component can be modelled. These interfaces may be modelled as classes that can reuse the \(\ll \)Quantum Request\(\gg \) stereotype previously depicted (cf. Sect. 4.3). Apart from those stereotypes, the deployment diagram in Fig. 10 uses other ordinary stereotypes already defined in UML (e.g., \(\ll \)device\(\gg \), \(\ll \)executionEnvironment\(\gg \), and \(\ll \)call\(\gg \)).