Quantum computing is getting closer and closer to being embedded in commercial information systems to provide a variety of services to companies and organizations. This is not an assumption, but a fact. We are now living in the quantum decade, where institutions are starting to realize the business value that this technology can provide.
Sometimes, when we talk about quantum computing, we may think that this domain of science belongs only to physics and mathematics, and that software engineering has nothing to do with it. However, this belief is totally wrong. Software engineering will play a crucial role when companies want (and are able) to evolve their current information systems towards a hybrid type of information system, combining both traditional and quantum computing by making use of the services of providers such as IBM, Google or Microsoft among others. Although software engineering can help in different ways in this evolution of systems, today we will focus on how Model-Driven Engineering can achieve this.
Modernization toward hybrid information systems
Quantum computing has great potential to change many of the sciences we know today. A large number of papers have been published in which, even if only theoretically for now, they show that certain algorithms developed based on the principles of quantum mechanics (which is where quantum computing comes from) can be very useful. This is because quantum computing can deal easily with certain types of problems that are nowadays highly demanding to our current systems (i.e., the number factorization).
Once the commercial quantum computers arrive (with an acceptable number of qubits), companies will migrate part of those classical systems that carry out complex operations or algorithms to quantum computers. The implementation of quantum computing does not necessarily imply a full replacement of the classical information systems, but at some point, both paradigms could work together, creating, as mentioned before, hybrid classical-quantum information.
The evolution of the systems does not imply discarding the whole classical information systems, given that they are still useful for their organizations. Those systems may embed a vast amount of critical-mission knowledge that probably is not located elsewhere, and their replacement is highly risky. Another reason not to discard the classical part of the systems is that there will be certain operations that, being so simple, their implementation using quantum computing will not lead to an increase in performance.
One of the possible solutions to address the evolution of the information systems could be through software modernization, which is the evolution of traditional reengineering but following an MDE approach. A solution based on reengineering and, more specifically on ADM, was already proposed to achieve the evolution of classical information systems to-wards hybrid ones. That solution introduced “Quantum software reengineering” and ensured that it might be used in three complementary scenarios:
- Migrate existing, isolated quantum algorithms and integrate them into the hybrid information systems.
- Migrate classical legacy information systems toward hybrid architectures that sup-port the integration of classical-quantum information systems.
- Transform or add new business operations supported by quantum software that will be integrated into the target hybrid systems.
The overall process of can Quantum Software Reengineering can be seen in Figure 1, which follows the three phases of traditional reengineering but is adapted to face the challenges that may occur during the evolution towards quantum computing. Those three phases consist in:
- Reverse engineering: the artifacts (either source code or database schemas) of the classical systems (scenario 1) and quantum if they exist (scenario 2) will be analyzed, and a KDM model will be generated. This model will represent, in a technology-agnostic way, the components and their interrelationships of the system. As the KDM approach does not define the different quantum components that may appear in the system, KDM was extended in order to being capable of working with those entities. This first phase was published and it can be seen in this link.
- Restructuring: consists of the transformation of the previously generated KDM models into different high-abstraction level models that may be used later to generate the target code. The metamodel chosen has been UML as it is a well-proven modelling language that has been widely employed in industry for some time. UML also follows the philosophy of the previous step for representing models in a technological-agnostic manner. As in the previous phase, UML was extended for working with the different quantum entities that may appear in the models coming from the KDM models. The transformation of KDM to UML models will be the focus of this post.
- Forward engineering: in this phase tools can be used to automatically generate code fragments of the hybrid system designed in UML. Although there are currently tools that generate code based on UML diagrams, they cannot automatically implement quantum algorithms.
Figure 1. Quantum Software Reengineering process.
Quantum metamodel extensions
Before starting to talk about how the transformation from KDM to UML models has been carried out, we believe it may be interesting to explain how metamodels have been extended to work with the different quantum components that may appear in the programs.
The first standard of the process, the Knowledge Discovery Metamodel-ISO /IEC 19506 is a standard developed for the modernization of those systems that have suffered the passing of time and the technology with which they have been developed is obsolete or close to being obsolete. This standard was the first of the set of standards proposed within ADM, and it provides a comprehensive view of the application structure and data, identifying the different components of the systems and their interrelationships and represents it in a technology-agnostic way at a higher abstraction level. The fact that the representations of the systems are technology-agnostic was an important factor at the time of selecting the standard because this allows us to make a common representation among all the different quantum programming languages and frameworks that now exist.
The default extension mechanism provided by KDM is the extension family. In this extension family, the different components that can be found in a quantum programming language are represented in this group, shown in Figure 2. This mechanism collects a set of stereotypes that are then used in the ordinary elements provided by KDM. Which is exactly what we want. This header is then added in each of the models generated and when a quantum component appears, in its description is added the identifier of its type in the extension family. A further explanation of this extension family can be seen in this paper.
Figure 2. Extension family of KDM for quantum components.
Now, for the second metamodel we chose UML. Because it is such an industry standard, there is a wide variety of tools for modelling diagrams using UML, and thus a wide knowledge of software engineers who have already worked with UML. To carry out the extension of the metamodel, UML provides us with different mechanisms. We chose to create a profile, which we named the UML Quantum Profile. Using a profile allows us, when generating UML models, to make them fully compliant with UML. This advantage would allow us to use existing modelling tools. In Figure 3 we can see the profile that will allow us to graphically represent quantum programs by means of activity diagrams. On the right side of the image, the stereotypes that have been added to be able to work with the different quantum entities are grouped together: quantum circuit, qubit, quantum gate, controlled qubit, measure and reset. The left side of Figure 3 shows the UML metamodel excerpt for representing UML Activity Diagrams. Leftwards arrows from stereotypes to metaclass elements are used to indicate that the properties of a metaclass are extended through the respective stereotype.
Figure 3. The Quantum UML Profile.
KDM to UML Model Transformation
Now that it is clear why we have to carry out a model transformation (to comply with the Quantum Software Reengineering process) and the peculiarities of these models (the extensions), it is time to talk about how we have actually defined the model transformation.
This transformation of models has been carried out using the Atlas Transformation Language. ATL is a model transformation language as a combination of declarative and imperative language that provides mechanisms to produce a set of target models compliant with the specified metamodel, from a set of source models. A key aspect in designing the model transformation is to define the input and output metamodels. The input metamodel is an extension of KDM which allows the identification of quantum elements through its extension family. The output metamodel is the ECORE metamodel for UML version 2.5.1, which defines the abstract syntax of UML. Having defined the metamodels, the design of the ATL transformation attempts to identify which quantum entities could match with elements of the UML metamodel. This identification of the elements with the metamodel is essential for the transformation.
The KDM-to-UML transformation followed a top-down order. Thus, the first KDM elements that were transformed to UML are those that group the remaining nested elements, i.e., the Segment element as the KDM model’s root element. Whilst the last, and more atomic, KDM element is the actionRelation, which specifies on which qubit a quantum gate acted and its flow control.
A simple example of model transformation can be seen in Figure 4 where the input model only contains the description of the root element (a comparison would be as if we had a Java file that only contains the description of a class) and a couple of children (the declaration of a qubit and a Hadamard quantum gate that is applied on the declared qubit). The root element in KDM has type CompilationUnit, because it defines a container of all the program elements and will be transformed into an element of type Interaction, which is its UML equivalent for modelling activity diagrams. In the middle of the Figure 4 we can observe the rule defined in ATL CompUnit2Interaction where it describes that the qubits of the input model will be transformed into edge and the Hadamard gates into ownedNode. Finally, the right side of Figure 4 shows the result of the transformation.
Figure 4. Quantum program transformation.
In Figure 5 we can see another example of how the transformation of KDM models to UML has been carried out in ATL, but we will focus on how the representations of the quantum gates are transformed in the models, more specifically the Hadamard gate. On the left side of Figure 5 we can see that the Hadamard gate is represented in KDM with the ActionElement type. Inside the ActionElement there are three children, one of type source and two of type actionRelation, which on the child of type Addresses is indicated on which qubit is that quantum gate applying and the another of type Flow indicates the identifier of the next quantum gate to represent the flow of information. In the middle of Figure 5, we can see that two rules have been defined, Address2CallOperation and Flow2ControlFlow. Within the first rule, we can see that it is specified that it will obtain the child of type Addresses and transform it into CallOperationAction where its attributes will come from the value obtained from the from and to attributes of Addresses.
Figure 5. Hadamard’s gate transformation.
Figure 6 shows the result of a complete transformation of a KDM model (left) to UML (right), more specifically, the transformation of the KDM model of the Quantum Teleportation algorithm developed in Microsoft’s quantum programming language, Q#. For reasons of length, the models are shown as a tree. In the KDM model (left of the Figure 6) we can find in the first lines the ExtensionFamily explained in previous sections. Subsequently, we can find the description of the root element CompilationUnit and the nested methods or functions defined in the Q# program and represented as Callable Unit. Within each Callable Unit are nested the qubit declarations (defined as StorableUnit) and the quantum gates. At the top of the UML model (right of the Figure 6) can be found result of the transformation from CompilationUnit to Interaction. In addition, each of the Callable Units has been transformed to Activity but keeping its corresponding name. Two important changes can be seen with respect to the KDM model: (i) the information flow is no longer defined through attributes of the quantum gates, but with elements of type Control Flow, and (ii) an Initial Node and a Final Node are declared in order to be even more explicit when describing the information flow. Another detail to highlight in the UML model is that each quantum gate, depending on the effect they have on the qubits, belongs to one type or another. A further explanation of the overall quantum transformation can be seen in this paper.
Figure 6. Example of a full quantum transformation.
Conclusions
In this post we have presented the process of Quantum Software Reengineering for allowing the evolution of classical information systems towards hybrid information systems. Following this process, the information systems will maintain all the embedded information that have acquired among time and so, its business rules. This process has three phases: reverse engineering, restructuring (which has been the scope of this post) and forward engineering.
Current standards and metamodels are not yet adapted to work with quantum components. This is a problem when hybrid information systems are about to be implemented in companies all over the world. We have chosen to extend the metamodels by creating an ExtensionFamily in the case of KDM and a profile in UML. The transformation of the KDM models to UML has been carried out using the ATL transformation language.
This proposal is limited by the fact that only Q# is the only quantum programming language that can parse and generate KDM models. We are working on implementing other programming languages such as OpenQASM3 or Qiskit. Another limitation could be that the transformation only generates UML activity diagrams, but more diagrams will be defined in the future as classes, sequence or even state.
Luis Jiménez-Navajas PhD student in Computer Science from the University of Castilla-La Mancha (Spain). Current member of the scientific research group aQuantum, working on the software modernization of classical-quantum information systems with specific focus on software reverse engineering.
Recent Comments