Reverse Engineering of Classical-Quantum Programs

Luis Jim

enez-Navajas

1 a

, Ricardo P

erez-Castillo

1 b

and Mario Piattini

2 c

aQuantum, Faculty of Social Sciences and IT, University of Castilla-La Mancha Talavera de la Reina, Spain

aQuantum, Information Technology and Systems Institute, University of Castilla-La Mancha Ciudad Real, Spain

Keywords:

Reverse Engineering, Quantum Computing, Software Modernization, Qiskit, Knowledge Discovery

Metamodel.

Abstract:

Quantum computing has emerged as a crucial technology, which is expected to be progressively integrated into

current, traditional information systems. Society could be beneﬁted from several potential, promising applica-

tions based on quantum computing. To achieve such advantages, this new paradigm will require integrating the

quantum software into the new hybrid (classical-quantum) information systems. Thus, it is necessary to adapt

well-known and validated software engineering methods and techniques, such as software evolution methods

based on Model-Driven Engineering principles. In particular, the proposal of this paper is framed in the Quan-

tum Software Modernization process, and, in particular, it addresses the reverse engineering phase. The main

contribution is a reverse engineering technique that analyses quantum (Qiskit) and classical (Python) code and

builds a common, abstract model that combines both classical and quantum elements. The models are built in

a technology-agnostic manner through the Knowledge Discovery Metamodel. Within this technique, relation-

ships have been established between classical and quantum elements which can help to preserve knowledge

and provide meaningful insights during the evolution toward hybrid information systems. The functioning of

this technique is demonstrated through a running example with a program from the Qiskit Github repository.

1 INTRODUCTION

In recent years, a great number of achievements have

been beheld in the ﬁeld of quantum computing. This

new technology is leading to promising applications

like the discovery of new drugs (Cao et al., 2018) or

new industrial solutions related to optimization prob-

lems (Bayerstadler et al., 2021) which, if they ﬁnally

succeed, will inevitably imply an impact on society.

Furthermore, the various providers of quantum com-

puting have enabled a truly accessible ecosystem for

the development of quantum software which favors

the development of this technology.

Although quantum computing is gaining more

and more importance, software engineering for quan-

tum software should be considered equally important

(Hoare and Milner, 2005). In order to develop high-

quality quantum software in an industrial and con-

trolled manner, it is necessary to adapt the knowledge

and lessons learned from the software engineering

ﬁeld, so the Quantum Software Engineering (QSE)

https://orcid.org/0000-0001-6257-7153

https://orcid.org/0000-0002-9271-3184

https://orcid.org/0000-0002-7212-8279

approach is essential (Piattini et al., 2020; Serrano

et al., 2022).

Companies that are eager to get beneﬁted from

quantum software, may want to adapt their classi-

cal software systems in order to adopt the quantum

computing paradigm. For example, companies re-

searching the creation of certain materials or pharma-

ceuticals will be forced to adopt quantum software,

since its performance is better than classical software

with these type of problems (Aaronson, 2008). How-

ever, discarding the classical information systems (as

a whole) and migrating them into quantum informa-

tion systems makes no sense as quantum computing

performs better than classical computing for speciﬁc

scenarios (those that may take advantage of quantum

parallelism or simulation of elements (Zhao, 2020)).

Thus, the migration toward pure quantum informa-

tion systems is very unlikely since the performance-

cost ratio could be degraded, among other reasons.

In contrast, it is expected to integrate quantum soft-

ware into the current information systems, leading to

the evolution toward the so-called hybrid information

systems. Typically, in these hybrid information sys-

tems, the classical part controls and receives all the

Jiménez-Navajas, L., Pérez-Castillo, R. and Piattini, M.

Reverse Engineering of Classical-Quantum Programs.

DOI: 10.5220/0012535000003687

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 19th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2024), pages 275-282

ISBN: 978-989-758-696-5; ISSN: 2184-4895

275

outputs generated by the quantum software compo-

nents, which is, generally, executed in remote quan-

tum computers in the cloud (Nguyen et al., 2022).

One of the approaches to address the evolution

toward hybrid software systems is software mod-

ernization. Software Modernization embraces the

traditional reengineering process by following the

Model-Driven Engineering (MDE) principles. Soft-

ware modernization has allowed organizations to de-

velop and evolve high-quality software in compliance

with standards and following well-proven practices

(Durelli et al., 2014). To make a successful evolution

from classical information systems to hybrid informa-

tion systems, the software modernization process has

been adapted to the ﬁeld of quantum software (Perez-

Castillo et al., 2021). This process of Quantum Soft-

ware Modernization alleviates problems that may oc-

cur during the analysis, design, and generation of hy-

brid information systems (P

erez-Castillo et al., 2024).

The Quantum Software Modernization process in-

volves three main phases: reverse engineering, re-

structuring, and forward engineering. This paper

speciﬁcally focuses on the reverse engineering phase.

This phase is crucial since is aimed at generat-

ing abstract representations of quantum and classi-

cal programs in combination. This proposal produces

abstract models in a technology-agnostic manner

through the usage of the Knowledge Discovery Meta-

model (KDM) (P

erez-Castillo et al., 2011). The re-

verse engineering technique analyzes the source code

of hybrid software programs developed in Python,

which import the Qiskit library (Aleksandrowicz

et al., 2019).

The remainder of the paper is structured as fol-

lows: Section 2 depicts the current state of the art

of quantum computing and classical-quantum soft-

ware modernization. Then, Section 3 introduces a

running example. Section 4 explains the proposed

reverse engineering technique and illustrates how it

works through the development of the running exam-

ple. Finally, Section 5 presents the conclusions ob-

tained from this research and future work.

2 BACKGROUND

This section introduces the underlying concepts re-

lated to the technique. Section 2.1 describes how

quantum software works. Section 2.2 presents the

software modernization process. Finally, Section 2.3

explains the adaption of software modernization to be

applied to the evolution of hybrid information sys-

tems.

2.1 Quantum Software

The Quantum Software Manifesto stated that “given

the recent rapid advances in quantum hardware, it

is urgent that we step up our efforts in quantum

software” (Ambainis et al., 2017), and the Euro-

pean Quantum Flagship´s Strategic Research Agenda

(EQF, 2020) proposes to investigate the “development

of software stacks to integrate quantum computing

into current computing environments”.

Currently, there are a large number of providers

that allow us to develop quantum software. The

world’s largest companies are already providing pro-

gramming languages and libraries that enable the de-

velopment of quantum software, i.e., OpenQASM,

Q#, Qiskit (IBM), Cirq (Google), pyQuil (Rigetti),

among others (Garhwal et al., 2019; Zhao, 2020).

Unfortunately, several quantum computer scien-

tists do not know the software engineering principles

and techniques, so several errors could be repeated,

and some expensive “rediscoveries” could happen

(Piattini et al., 2021). Nevertheless, with the advent

of “industrial” quantum software and its increasing

use in various business domains, there is a growing

demand for quantum software to be produced more

systematically, as stated in the Talavera Manifesto

for Quantum Software Engineering and Programming

(Piattini et al., 2020).

2.2 Software Modernization

The course of time also affects information systems,

forcing them to evolve continuously. Those systems

that were developed in the past can be affected by

degradation or aging, turning them into legacy infor-

mation systems, which means that the source code

which has been developed could be technologically

obsolete (Ulrich, 2002). The evolution of legacy sys-

tems is a duty that has been addressed for years since

many companies cannot simply discard such systems,

as they possibly embed a large amount of business

logic and business rules that are not depicted else-

where (Sommerville, 2011).

Reengineering is a successful practice in the soft-

ware industry, consisting of three phases: reverse

engineering, restructuring, and forward engineering.

However, when faced with speciﬁc challenges, this

practice has more than half of the traditional reengi-

neering projects fail because of a lack of standard-

ized and automated processes (Sneed, 2005). This is

why the OMG proposed ADM as a possible mecha-

nism for software evolution, which consists of apply-

ing reengineering with an MDE approach. For the re-

verse engineering phase, ADM advocates the use of

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

276

KDM to abstract and represent all the software ar-

tifacts that can be found in a legacy system. This

representation is done in a standard and technology-

independent way.

2.3 Quantum Software Modernization

The future implementation of quantum software or

services in our information systems will inevitably

lead to an evolution of information systems to adopt

this software. This does not imply the complete re-

placement of classical information systems by quan-

tum software but rather a modernization of these sys-

tems integrating new quantum software components.

To this end, the software modernization process has

been adapted to the domain of quantum computing

(see Fig. 1).

The Quantum Software Modernization process

was ﬁrst proposed in (Jim

enez-Navajas et al., 2020)

and consists of the same phases as classical reengi-

neering: reverse engineering, restructuring, and for-

ward engineering. In the reverse engineering phase

(the scope of this paper), software artifacts are an-

alyzed, and their components and interrelationships

are represented at a higher level of abstraction. For

this proposal, classical and quantum code has been

analyzed and represented using KDM models. The

restructuring phase consists of improving the inter-

nal structure of the model (either by modifying or

adding functionalities) but preserving the behavior of

the system. Finally, in the forward engineering phase

through generative and low-code techniques, the tar-

get classical-quantum information system is gener-

ated in a semi-automatic way.

3 RUNNING EXAMPLE

This section presents a running example which in the

following sections will be elaborated on based on the

proposed technique to illustrate how the reverse en-

gineering technique works. It should be mentioned

that this example has been entirely conducted using

a supporting tool that has been developed (Jim

enez-

Navajas et al., 2023a). The input of the technique is

a basic program extracted from the Qiskit repository

(Aleksandrowicz et al., 2019) and using Qiskit’s ver-

sion 0.41. This example can be seen in Listing 1. Al-

though the complete program consists of two circuits,

only the ﬁrst circuit (everything referred to with qc1)

will be explained hereinafter due to length limits. The

KDM representation of the complete program can be

obtained from (Jim

enez-Navajas et al., 2023b).

KDM Models UML Models

Existing

Quantum

Programs

Classical

Information

System

Target Classical-

Quantum

System

New Quantum

Software

Reverse

Engineering

Forward

Engineering

Restructuring

Figure 1: Quantum software modernization process.

1 # making f i r s t c i r c u i t : b e l l s t a t e

2 q c1 = Q u a n t u m C i r c u i t ( 2 , 2)

3 q c1 . h ( 0 )

4 q c1 . cx ( 0 , 1 )

5 q c1 . measure ( [ 0 , 1 ] , [ 0 , 1 ] )

7 # making a n o t h e r c i r c u i t : s u p e r p o s i t i o n s

8 q c2 = Q u a n t u m C i r c u i t ( 2 , 2)

9 q c2 . h ( [ 0 , 1 ] )

10 q c2 . measure ( [ 0 , 1 ] , [ 0 , 1 ] )

12 # s e t t i n g up t h e b a c k e n d

13 p r i n t ( ” ( BasicAER Back e n d s ) ” )

14 p r i n t ( B a s i cA e r . b a c k en d s ( ) )

16 # r u n n i n g t h e j o b

17 j o b si m = e x e c u t e ( [ qc1 , qc2 ] , B a si c A e r . g e t b a c k e n d ( ”

q a s m s i m u l a t o r ” ) )

18 s i m r e s u l t = j o b s i m . r e s u l t ( )

20 # Show t h e r e s u l t s

21 p r i n t ( s i m r e s u l t . g e t c o u n t s ( qc1 ) )

22 p r i n t ( s i m r e s u l t . g e t c o u n t s ( qc2 ) )

Listing 1: Python program consisting of two quantum

circuits.

The declaration of a quantum circuit can be seen

in line 2. This circuit will have two qubits and two

classical registers. These last two registers will be

used later to store the values obtained from the mea-

surements of the qubits. Next, in line 3, a Hadamard

gate is applied to the ﬁrst qubit of the qc1 circuit. This

gate has the function of setting the qubits in a super-

position state, i.e., it causes the qubits to have two

different states simultaneously. In line 4, the Con-

trolled Not gate is applied to qubits 0 and 1. The

function of this gate is to perform a negation on the

second qubit (target) if the state of the ﬁrst qubit (con-

trol) is |1⟩. In line 5, a measurement operation is

applied to qubits 0 and 1 and stored in the classical

registers 0 and 1, respectively. This measurement un-

does the superposition of the qubits and reveals their

state, setting them to |0⟩ or |1⟩ until another quantum

gate is reapplied and changes their state. Finally, in

lines 17 and 18, the circuit is executed in the back-

end of qasm simulator, and the results are stored in

the variable sim result.

Reverse Engineering of Classical-Quantum Programs

277

4 REVERSE ENGINEERING OF

HYBRID QUANTUM

SOFTWARE

For the representation of the hybrid programs, an ap-

proach where two models are represented within the

same KDM segment, composed of a classical and a

quantum software model has been followed. On the

one hand, in the classical software model (cf. Sec-

tion 4.1), the whole Python program is represented,

including the Qiskit code. This means that Qiskit

(quantum) elements are depicted as mere classical

functions. On the other hand, in the quantum soft-

ware model (cf. Section 4.2), the underlying quantum

circuit is abstracted from the embedded Qiskit code.

The representation of these models in combination is

the main contribution of this technique since it en-

ables the creation of valuable relations between ele-

ments of the two models (cf. Section 4.3). Modelling

such relationships can help us to answer interesting,

valuable questions during the software modernization

process. These questions are the following (although

this is not a limited list):

• RQ1. What classical data elements are going to

receive and manage results from the quantum soft-

ware component?

• RQ2. What classical parts are involved in the dy-

namic generation of a quantum circuit?

• RQ3. What quantum circuits are controlled and

executed by speciﬁc classical drivers?

This technique has been divided into two phases.

The ﬁrst phase consists of the static analysis of the

hybrid programs and their representation through an

Abstract Syntax Tree (AST). The second phase takes

the AST as input and generates KDM representations

of each element embodied in the tree depending on its

function in the program.

For the ﬁrst phase analysis of the hybrid programs,

ANother Tool for Language Recognition (ANTLR)

has been employed (Parr, 2013). This tool allows

parsing source code and representing it in an AST

by deﬁning the grammar and lexicon on which the

ﬁle is based. Program parsing is divided into two

phases: lexical analysis and parsing. In the lexical

analysis phase, characters are grouped into words or

other characters (tokenize), and this is done by a lexer

based on Python code. The second stage is the actual

parser which feeds off these tokens to recognize the

sentence structure, in this case, an assignment state-

ment.

In the lexical analysis phase, the Python3 lexicon

and grammar available in the ANTLR GitHub reposi-

tory has been used as a starting point since Qiskit is a

library of this language (Everet, 2020). However, this

grammar had to be modiﬁed so that in the next phase,

some quantum elements could be identiﬁed in a bet-

ter way. For the running example presented, Listing 2

shows an example of the modiﬁcation in the Python3

lexer ﬁle. In the running example, there are only three

quantum gates: a Hadamard gate, a Controlled Not

gate, and a measure operation (the implementation of

these can be seen in Listing 1). Adding these lines to

the lexicon ﬁle three new tokens are deﬁned. After-

wards, in the parser ﬁle it is deﬁned how each these

tokes are grouped and represented.

1 / / Q i s k i t ’ s Quantum G a t es

2 HADAMARD : ’ h ’ ;

3 CONTROLLEDX : ’ cx ’ ;

4 MEASURE : ’ me a s u r e ’ ;

Listing 2: Quantum gates deﬁned on the lexer.

Having analyzed the programs and built the AST

model, it is then necessary to deﬁne how each of the

elements of the tree will be represented in certain

parts of the KDM model. Section 4.1 explains how

these elements are modelled for the classical soft-

ware model, and Section 4.2 the same mapping for

the quantum software model. Finally, Section 4.3 dis-

cusses the relationships that are established between

the two models.

4.1 Classical Software Model

The classical representation of the hybrid programs

(based on Qiskit-Python code) deﬁnes how each el-

ement must be represented in KDM. All variables

that will save any result are represented using the

code:StorableUnit type, while functions are repre-

sented using the action:ActionElement type. Also,

each element appearing in the classical software

model has a child of type action:CompliesTo aim-

ing to its corresponding LanguageUnit deﬁnition. A

LanguageUnits represents predeﬁned data types and

other common elements determined by a particular

programming language. This LanguageUnit has the

function of helping the model to preserve as much in-

formation as possible.

Fig. 2 shows (through the Eclipse IDE model

viewer) part of the outgoing KDM model represent-

ing the classical software model of Listing 1. At

the beginning of the model, there are three code:

StorableUnit elements. One is the quantum reg-

ister where all the quantum operations point to any

of the respective indexes, another is the classical reg-

ister where the measurements of the operations per-

formed on the quantum register are stored and the

last one is the variable that stores the two registers

(so, the quantum circuit). When a circuit is de-

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

278

clared using the Qiskit library, the variable that de-

clares it holds a quantum register and a classical

is qc1=QuantumCircuit(2,2) which represents the

action of declaring a circuit with two qubits and two

classical registers. Afterward, all the quantum gates

used in the circuit are represented (Hadamard, Con-

trolled Not, and Measure) and then two print state-

ments (classical functions). Finally, the algorithm

is executed with the execute statement and the re-

sults are stored in the variable job sim, so another

code:Storable Unit is declared. With the function

result the results of the execution of a circuit are

saved. Since those results must be stored in another

variable, an additional sim result was declared. Fi-

nally, there is a print statement that displays the re-

sults of sim result.

Figure 2: Classical software model generated.

Fig. 3 shows the LanguageUnit generated from

the circuit. Two LanguageUnit have been modelled:

one for Qiskit and another for Python. Each of these

LanguageUnit elements contain the description of

the elements of the programming language to which

this LanguageUnits corresponds to. Thus, the Qiskit

LanguageUnit only contains those elements that are

used in the program and deﬁned by Qiskit (data types,

quantum gates, etc.). This means that in the classic

model of the example, two Python elements are used

during the development of the program: a print state-

ment and an integer value deﬁnition.

4.2 Quantum Software Model

The quantum software model abstracts the underly-

ing quantum circuit that is derived from the embed-

ded Qiskit source code. Abstracting this model is

not straightforward since many quantum circuits are

built dynamically with external data sources. The

approach taken for the representation could be con-

sidered similar to (Jim

enez-Navajas et al., 2020),

where all the different quantum elements are associ-

ated with a stereotype from the extension family.

Figure 3: LanguageUnits generated.

That extension family allows the extension of the

semantics of KDM to represent all the quantum ele-

ments that may appear in a program, applying them

to the elements represented with the metamodel deﬁ-

nition.

Fig. 4 provides the KDM representation of the

quantum software model in Listing 1. In contrast to

the classical software model, this model is shorter.

This is because the underlying quantum circuit de-

rived from the Qiskit code is abstracted. This implies

representing only the quantum gates applied to the

deﬁned circuit. Also, it can be seen how the differ-

ent quantum gates that perform actions to the circuit

qc1 are nested to it, as well as the number of qubits

that were declared. Each of these quantum gates has a

stereotype attribute referencing the stereotype iden-

tiﬁer in the extension family. Another important

detail is that two measure operations appear since

in this pure quantum software model the measure-

ment that was performed (see Listing 1) over two

qubits at the same time has been represented as two

different measure operations. All these elements of

the quantum software model are deﬁned in the Qiskit

LanguageUnit (see Fig. 3).

Figure 4: Quantum software model generated.

Reverse Engineering of Classical-Quantum Programs

279

4.3 Modelling of Classical-Quantum

Relationships

The deﬁnition of these relationships is the main con-

tribution of this research. In the proposed technique,

two different models (one classical and one hybrid)

are represented in the same KDM segment, and rela-

tionships between elements of those two models are

established. Three KDM mechanisms are used to de-

ﬁne relationships: the code:CodeRelationship el-

ement and the to attribute of the action:Writes of

the qubit measurement operations, and the association

between the element action:Reads in the represen-

tation of the execute function with the quantum cir-

cuit declared in the classical software model.

Fig 5 shows an excerpt of the outgoing quantum

and classical KDM model representations for the dec-

laration of the quantum circuit, the measurement of

the two qubits declared, and the execution of qc1 (see

lines 2, 5, and 7 in Listing 1, respectively).

In the classical software model, the three ﬁrst el-

ements represent the code:StorableUnit elements.

The two ﬁrs code:StorableUnit elements have a

type attribute whose value points, respectively, to

the description of the Quantum and Classical regis-

ters. Then, the action:ActionElement represents

the declaration of the circuit that it has as children:

• The value of the ﬁrst and parameters with the

type pointing to the deﬁnition of the Quantum and

Classical Registers in the LanguageUnit, respec-

tively.

• The relation indicating that the declaration of the

circuit is compliant with the Qiskit deﬁnition,

pointing to the element ”Quantum Circuit” of the

LanguageUnit.

• The relation that indicates on which

code:StorableUnit the circuit will be de-

clared, i.e., qc1

Regarding the measurement operation rep-

resentation, it is represented employing an

action:ActionElement that has as children:

• The programming language to which it belongs.

• The relation pointing to which quantum circuit is

acting, in this case, qc1.

• The relation pointing to which registers it affects.

• Both the child with type Calls and

action:CompliesTo point to the same identiﬁer,

which is the description of the measurement

operation in the LanguageUnit.

• The value of the parameter used in the gate, with

type pointing to the deﬁnition of the Quantum

• The relation indicates that the value sent by the

parameter is read.

• The relationship that associates the quantum reg-

ister’s itemUnit.

• The value of the parameter used in the gate where

the value of the qubit is going to be stored, with

type pointing to the deﬁnition of the Classical

• The relation indicates that the value sent by the

parameter is read.

• The relationship that associates the classical reg-

ister’s itemUnit.

Concerning the representation of the execution

of the circuit, ﬁrst, the declaration of the vari-

able where the results of the operation will be

stored is represented. Then, an element of action:

ActionElement that represents what the function

execute performs is shown. This element has the

children:

• An action:Reads element that refers to the

quantum circuit that is reading.

• An action:CompliesTo element that indicates

which element of the LanguageUnit it complies

to.

• An action:Writes element associated with the

variable declared in the previous line to represent

the writing on it.

Regarding the quantum software model,

the quantum circuit is deﬁned using a nested

code:CallableUnit, containing all the quantum

elements related to it (e.g., the qubits declared and

the quantum gates used in the circuit). In particular,

the nested elements are the following:

• The code:CodeRelationship element re-

lating the quantum circuit representation in

the quantum and the classical software mod-

els, with the stereotype associated with the

quantum circuits relationship.

• The two qubits declare the circuit through the

code:Storable Unit element. Both point to the

extension family stereotype qubit.

• The gate measure with the type

action:ActionElement to indicate that it

does an action type, which in this case indicates

that it does a read on qubit0 thanks to its child

element of type action:Reads that points from

the quantum gate identiﬁer to the identiﬁer

of the qubit on which it is applied. Immedi-

ately afterward, using a child element of type

action:Writes that references to the classical

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

280

Classical model

1 <codeElement xmi:id="id.51" xmi:type="code:CompilationUnit">

2 <codeElement xmi:id="id.54" xmi:type="code:StorableUnit" name="quantumRegister" type="id.20" />

3 <codeElement xmi:id="id.55" xmi:type="code:StorableUnit" name="classicalRegister"type="id.22" />

4 <codeElement xmi:id="id.52" xmi:type="code:StorableUnit" name="qc1" kind="local" />

5 <codeElement xmi:id="id.53" xmi:type="action:ActionElement" name="qc1=QuantumCircuit(2,2)" kind="New">

6 <codeElement xmi:id="id.56" xmi:type="code:Value" name="2" type="id.20" />

7 <codeElement xmi:id="id.57" xmi:type="code:Value" name="2" type="id.22" />

8 <actionRelation xmi:id="id.58" xmi:type="action:CompliesTo" from="id.53" to="id.24" />

9 <actionRelation xmi:id="id.59" xmi:type="action:Writes" from="id.53" to="id.52" />

10 </codeElement>

11 <codeElement xmi:id="id.79" xmi:type="action:ActionElement" kind="Call" name="Measure">

12 <source language="Qiskit" snippet="qc1.measure([0,1],[0,1])" />

13 <actionRelation xmi:id="id.92" xmi:type="action:Addresses" from="id.79" to="id.52" />

14 <actionRelation xmi:id="id.93" xmi:type="action:Addresses" from="id.79" to="id.54" />

15 <actionRelation xmi:id="id.96" xmi:type="action:Addresses" from="id.79" to="id.55" />

16 <actionRelation xmi:id="id.95" xmi:type="action:Calls" from="id.79" to="id.40" />

17 <actionRelation xmi:id="id.94" xmi:type="action:CompliesTo" from="id.79" to="id.40" />

18 <codeElement xmi:id="id.80" xmi:type="code:Value" name="0" type="id.20" />

19 <actionRelation xmi:id="id.81" xmi:type="action:Reads" from="id.79" to="id.80" />

20 <actionRelation xmi:id="id.82" xmi:type="action:Reads" from="id.79" to="id.21" />

21 <codeElement xmi:id="id.86" xmi:type="code:Value" name="0" type="id.22" />

22 <actionRelation xmi:id="id.87" xmi:type="action:Reads" from="id.79" to="id.86" />

23 <actionRelation xmi:id="id.88" xmi:type="action:Writes" from="id.79" to="id.23" />

24 </codeElement>

25 <codeElement xmi:id="id.108" xmi:type="code:StorableUnit" name="job_sim" type="id.23" kind="register"/>

26 <codeElement xmi:id="id.109" xmi:type="action:ActionElement" name="job_sim = execute(qc1,BasicAer.get_backend(qasm_simulator)">

27 <actionRelation xmi:id="id.112" xmi:type="action:Reads" from="id.109" to="id.52" stereotype="id.12"/>

28 <actionRelation xmi:id="id.111" xmi:type="action:CompliesTo" from="id.109" to="id.45"/>

29 <actionRelation xmi:id="id.110" xmi:type="action:Writes" from="id.109" to="id.108"/>

30 </codeElement>

Quantum model

31 <codeElement xmi:id="id.122" xmi:type="code:CallableUnit" name="qc1" stereotype="id.2">

32 <codeRelation xmi:type="code:CodeRelationship" from="id.122" to="id.52" stereotype="id.10" />

33 <codeElement xmi:id="id.123" xmi:type="code:StorableUnit" name="qubit0" stereotype="id.5" />

34 <codeElement xmi:id="id.124" xmi:type="code:StorableUnit" name="qubit1" stereotype="id.5" />

35 <codeElement xmi:id="id.130" xmi:type="action:ActionElement" kind="operator" name="Measure" stereotype="id.4">

36 <source language="Qiskit" snippet="MEASURE(0)" />

37 <actionRelation xmi:id="id.131" xmi:type="action:Reads" from="id.130" to="id.123" stereotype="id.6" />

38 <actionRelation xmi:id="id.132" xmi:type="action:Writes" from="id.130" to="id.55" stereotype="id.11" />

39 </codeElement>

40 <codeElement

RQ3

RQ2 RQ1

Figure 5: Excerpt of the output KDM model.

software model, it indicates where the results of

the operations performed are stored.

The lines have been chosen to be represented to

see graphically the relationships between both mod-

els. The green line indicates which classical register

modelled in the classical software model will store

the results from a measurement operation of a quan-

tum circuit. This relationship relates to the classi-

cal and quantum software models, pointing out which

classical element is saving the state of a qubit. With

this relation, we can answer (RQ1), as we can obtain

which data elements are receiving the results from

the qubit measuring as well as know which elements

could manage those results. The black line for the

relationship of the representation of the quantum cir-

cuit between the classical and the quantum software

model. This relationship also associates the descrip-

tion of the quantum circuit in the classical and the

quantum software model, but this time we could an-

swer questions related to the inﬂuence of classical el-

ements in the generation of quantum circuits (RQ2).

Finally, the yellow line indicates which quantum cir-

cuit will be executed. With this relationship, the ﬁnal

executed circuit can be tracked if the relationship is

followed, and the variable which stores the quantum

circuit can be obtained. This can help us to answer

questions related to which circuit is controlled and ex-

ecuted by speciﬁc classical drivers (RQ3).

5 CONCLUSIONS

This paper has presented a reverse engineering tech-

nique that analyses hybrid (classical-quantum) pro-

grams developed using Python-Qiskit. For this pur-

pose, a parser for Python source code is adapted to

represent the different quantum elements that may be

used in a hybrid program in the AST model. Then,

the relevant nodes of the AST model are represented

based on the standard KDM. This representation is

divided into two models: a classical software model

representing the program; and a quantum software

model representing the ﬁnal underlying quantum cir-

cuit. These two models are related to a set of interrela-

tionships that associate the quantum elements in both

models. A running example is conducted to illustrate

how this new technique works.

This technique helps to improve the quantum soft-

ware modernization process since the representations

of both models and the relationships established be-

tween them help to extract valuable insights and an-

swer interesting questions. This is important since in

the near future, different organizations will have to

address the task of modernizing their information sys-

tems to be beneﬁted from the promising applications

derived from quantum computing.

In future work, the design in KDM of more ele-

ments will be addressed. With this, the representation

of as many programs as possible using this technique

is an objective in the near term.

Reverse Engineering of Classical-Quantum Programs

281

ACKNOWLEDGEMENTS

This work is part of the projects PID2022-137944NB-

I00 (SMOOTH Project) and PDC2022-133051-

I00 (QU-ASAP Project) funded by MCIN/AEI/

10.13039/501100011033 / PRTR, EU.

REFERENCES

Aaronson, S. (2008). The limits of quantum. Scientiﬁc

American, 298(3):62–69.

Aleksandrowicz, G., Alexander, T., Barkoutsos, P., Bello,

L., Ben-Haim, Y., Bucher, D., and et al. (2019).

Qiskit: An Open-source Framework for Quantum

Computing.

Ambainis, A. et al. (2017). Quantum software manifesto.

Bayerstadler, A., Becquin, G., Binder, J., Botter, T., Ehm,

H., Ehmer, T., Erdmann, M., Gaus, N., Harbach, P.,

Hess, M., et al. (2021). Industry quantum computing

applications. EPJ Quantum Technology, 8(1):25.

Cao, Y., Romero, J., and Aspuru-Guzik, A. (2018). Poten-

tial of quantum computing for drug discovery. IBM

Journal of Research and Development, 62(6):6–1.

Durelli, R. S., Santib

nez, D. S. M., Marinho, B., Honda,

R., Delamaro, M. E., Anquetil, N., and de Camargo,

V. V. (2014). A mapping study on architecture-driven

modernization. In Proceedings of the 2014 IEEE 15th

International Conference on Information Reuse and

Integration (IEEE IRI 2014), pages 577–584.

EQF (2020). European quantum ﬂagship strategic research

agenda.

Everet, T. (2020). Python3 grammar developed in antlrv4.

Garhwal, S., Ghorani, M., and Ahmad, A. (2019). Quan-

tum programming language: A systematic review of

research topic and top cited languages. Archives of

Computational Methods in Engineering, 28.

Hoare, T. and Milner, R. (2005). Grand challenges for com-

puting research. The Computer Journal, 48(1):49–52.

Jim

enez-Navajas, L., P

erez-Castillo, R., and Piattini, M.

(2020). Reverse engineering of quantum programs to-

ward kdm models. In Shepperd, M., Brito e Abreu,

F., Rodrigues da Silva, A., and P

erez-Castillo, R.,

editors, Quality of Information and Communications

Technology, pages 249–262, Cham. Springer Interna-

tional Publishing.

Jim

enez-Navajas, L., P

erez-Castillo, R., and Piattini, M.

(2023a). Github’s repository of the technique.

Jim

enez-Navajas, L., P

erez-Castillo, R., and Piattini, M.

(2023b). KDM representation of the program ”us-

ing qiskit terra level 0.py”.

Nguyen, H. T., Usman, M., and Buyya, R. (2022). Qfaas: A

serverless function-as-a-service framework for quan-

tum computing. arXiv preprint arXiv:2205.14845.

Parr, T. (2013). The deﬁnitive antlr 4 reference. The Deﬁni-

tive ANTLR 4 Reference, pages 1–326.

erez-Castillo, R., De Guzman, I. G.-R., and Piattini,

M. (2011). Knowledge discovery metamodel-iso/iec

19506: A standard to modernize legacy systems.

Computer Standards & Interfaces, 33(6):519–532.

Perez-Castillo, R., Serrano, M. A., and Piattini, M. (2021).

Software modernization to embrace quantum technol-

ogy. Advances in Engineering Software, 151:102933.

Piattini, M., Peterssen, G., P

erez-Castillo, R., Hevia, J. L.,

Serrano, M. A., Hern

andez, G., de Guzm

an, I. G. R.,

Paradela, C. A., Polo, M., Murina, E., et al. (2020).

The talavera manifesto for quantum software engi-

neering and programming. In QANSWER, pages 1–5.

Piattini, M., Serrano, M., Perez-Castillo, R., Petersen, G.,

and Hevia, J. L. (2021). Toward a quantum software

engineering. IT Professional, 23(1):62–66.

erez-Castillo, R., Serrano, M. A., Cruz-Lemus, J. A., and

Piattini, M. (2024). Guidelines to use the incremen-

tal commitment spiral model for developing quantum-

classical systems. Quantum Information and Compu-

tation, 24(1&2):71–88.

Serrano, M. A., Perez-Castillo, R., and Piattini, M. (2022).

Quantum Software Engineering. Springer Nature.

Sneed, H. M. (2005). Estimating the costs of a reengineer-

ing project. In 12th Working Conference on Reverse

Engineering (WCRE’05). IEEE.

Sommerville, I. (2011). Software Engineering, 9/E. Pearson

Education India.

Ulrich (2002). Legacy systems: transformation strategies.

Prentice Hall PTR.

Zhao, J. (2020). Quantum software engineering: Land-

scapes and horizons.

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

282