# On the Definition of Quantum Programming Modules
## 3 Towards Modular Quantum Programming
### Cohesion and Coupling Levels for Quantum Modules  
After the definition of quantum module and its main characteristics, we can now tackle the study of the cohesion and coupling levels. We followed, to some extent, the naming conventions of cohesion levels from classic programming; however, in some cases, we adopted new names and constraints, according to the quantum context. From best to worst, we considered that a module U can have functional, sequential, communicational, and clustered cohesion. For all the definitions we always assumed the same Hilbert space and communicational basis among the quantum information exchanged by modules. We argued that a module \(U\) has functional cohesion when its sub-modules contribute to the realization of a single well-defined task. Figure 9 shows an example of functional cohesion, where there is a module (called \"incr\") for incrementing an integer number represented by three qubits. Please note that the other constraints coming from the definition of module were also fulfilled (specially, its reversibility). Functional cohesion is the greatest level and the most desirable in terms of reuse and modifiability of a QP. When the module performs more than one task, but still the order in the execution of the gates is relevant, we say that the module \(U\) has sequential cohesion, being a lower level than functional one. An example could be a module performing the increment and the multiplication by a factor of two. The next level is communicational cohesion. We consider that a module \(U\) has communicational cohesion when the embedded sub-modules use, each, only a subset of the input qubits to carry out separate tasks, and their partial results are returned by the module. Figure 8: Sample of reusable module for solving a 3-SAT to find whether exists a combination of the three Boolean inputs to evaluate as true a given logic expression (image obtained using the [[https://algassert.com](https://algassert.com)]([https://algassert.com](https://algassert.com)) tool, accessed on 23 June 2021). Figure 9: Circuit including the reuse of a module (called “incr” and detailed on the right side) with functional cohesion (image obtained using the [[https://algassert.com](https://algassert.com)]([https://algassert.com](https://algassert.com)) tool, accessed on 23 June 2021). However, there are some execution dependencies among some of the tasks. Figure 10 shows the situation of a module that computes both the Boolean OR and AND operations (the last two qubits of the circuit are where the outputs are calculated and stored). This level of cohesion is not desirable because the reuse of the module is not so feasible. It should be preferrable to split the tasks of \(U\) into two separate modules embedded sequentially into the circuit, as is taught on first year courses on classical programming. Finally, a module has clustered cohesion when the embedded sub-modules carry out independent tasks that overlap in time, and therefore, there is no order. A control qubit can activate or deactivate the execution of some tasks of the module. This is the worst level of cohesion because it greatly prevents the reuse of the module. Coupling is a metric used to measure the degree of interdependence between software modules. In this case there is no direct correspondence with the coupling levels of classical software as the concept of \"module call\" does not exist as such in quantum programming. In this context, we studied two situations: (a) the coupling between a module (Ma) and the submodules (M\({}_{\text{a,i}}\)) used to build M\({}_{\text{a}}\), and (b) the coupling between the submodules Ma,i themselves as part of the realization of M\({}_{\text{a}}\). Regarding (a), we argued that M\({}_{\text{a,i}}\) is data coupled with Ma when the only information exchanged between the Ma and M\({}_{\text{a,i}}\) is a subset of the qubits handled by Ma. This is the coupling level by default.