# On the Definition of Quantum Programming Modules
## 3 Towards Modular Quantum Programming
### Background on Modularity in Quantum Programming  
In general, modularization is the process of breaking down a software into several modules, each one developed separately. One module should have limited or no dependency on other modules, in such a way that introducing changes in one of them affects the minimum number of other modules in order to reduce error propagation and maximize reuse. Modules also reduce intellectual burden on programmers, who can focus on just the functionality offered by the module. This concept has permeated and is present, in various forms, in all \"traditional\" programming languages. Quantum programming, with its special and counterintuitive rules and principles, should not be an exception to the inclusion of modules. Problem decomposition and module reuse have served us very well over the last 50 years in computer science (and for centuries to Humankind in other disciplines), and we should at least try to include modules and its key features into this new software development paradigm. However, to be able to talk about problem decomposition and reuse, we first need to explore the minimum reuse unit, the module, as well as the rules that constraint how to integrate and connect these units to other parts of a QP. Module independence is a key characteristic of any design. To measure it, at least qualitatively, the concepts of cohesion and coupling have been defined [16]. Cohesion is a measure of the relationship strength of the elements included in the definition of the module. In classical structured programming, seven levels of cohesion are distinguished, ranging from functional (the best) to co-incidental (the worst). Inter-related with cohesion, coupling measures the relationship strength among modules themselves. Six types of coupling have been distinguished, ranging from data (the best) to content (the worst). A good software system design should look for designing modules with high cohesion and low coupling [26]. These quality attributes have guided software developers for decades to achieve software systems of the highest possible quality. In the context of quantum programming and to our knowledge, there is only one work analyzing the concepts of module, cohesion, and coupling. In [14], several quantum architecture design characteristics to measure these attributes were identified. It distinguished two levels of cohesion, depending on the use of qubits superposition (temporal cohesion) and the existence of \"correlation between neighbouring qubits in order to interact\". Regarding coupling, the authors identified four levels, ranging from measure coupling (which exists between a quantum state and its environment) to non-coherent coupling (caused by loss of energy from emission of photon to the environment). From our point of view, both cohesion and coupling are defined there from a hardware perspective, and therefore, are not a useful tool for software modeling. Moreover, the definition of module is not clearly stated. Prior to these definitions, we must clearly define what a module is or can be in quantum computing terms. In [17], a formal framework for introducing modularity in quantum circuits is included. They demonstrate that it is not always possible to reuse a quantum circuit without knowing its implementation and, in certain situations, a small change in the algorithm can lead to a fully re-conception of the quantum circuit itself. Figure 3 shows an example of an abstracted quantum circuit with two slots to parametrize different implementations of unitary transformations (\(U\)), which range over the set of possible inputs \(\{U\}\). We can have many algorithmic realizations of each \(U_{x}\), provided that each one produces the same output (at the vector level) given the same input.