# On the Definition of Quantum Programming Modules
## 4 Discussion
In terms of module parameterization, we identified two scenarios at the design level: (1) when including gates with a concrete configuration parameter (e.g., indicating the angle of the phase rotation gate) into a module, (2) when considering a conceptual parameterization at the schematic design level (e.g., the one we have when it is indicated to the phase estimation algorithm that it receives the operator \(U\) on which such estimation is made). In the first case, the parameterization is seen as the concrete realization of the gate being embedded on the module. In the second case, it is an abstract representation aspect of the algorithm whose only implication is the fact that when implementing the specific algorithm, the gates necessary for its implementation have been included as part of the module realization (in the case of the example of phase estimation, it would be equivalent to the unitary operator \(U\) on which the invoked estimation is made, applying all the controlled operations \(C-U^{2}\)). The first scenario is fully compatible with the definition of module provided above. However, the second one requires a deeper research since in theory it would be possible to provide a concrete operation \(U\) that could make the whole module not valid according to our definition. From our point of view, one important contribution comes from the definition of domain-specific languages for quantum software development (QDSL). To that aim, the extensions of the UML notation for enabling classical and quantum aspects to be modeled together are very useful for software developers (for example, see the quantum UML profile introduced in [12] to design and model quantum circuits using UML activity diagrams). Together with the use of QDSL, another major contribution to the establishment of quantum software engineering discipline comes from working on the use of patterns [10]. The definition of a repository of useful patterns will serve as generic way solutions to recurring problems in the context of quantum computing. The independence of platform implementations, assumed by the definition of pattern itself, is still a matter of research in the quantum computing field given the differences between quantum execution platforms. Nevertheless, it serves as a very interesting starting point for the success of the quantum software engineering. The combination of patterns with a QDSL for defining not only the patterns, but also the quantum applications using these patterns, would be tremendously useful for software practitioners. It is needed a means to support not only the definition of patterns and the combination of them, but also a refinement process to directly applicate these patterns to concrete solutions modeled using the QDSL. This needs to be done taking into consideration the previously mentioned limitations of unitary transformations reuse and having a well-defined concept of module. Prior to the definition of QDSLs and patterns for reuse, the software engineering community must agree upon adopting a set of common criteria, including the definition of quantum program modules and a way to measure their modularity. The promotion in short term of reuse facilities and the achievement of the well-known benefits from traditional software modeling techniques is, without a doubt, of great interest for the adoption of software engineering techniques in quantum computing discipline. As stated in [32], there is some urgency in developing and adapting classical software engineering techniques to the new challenge of quantum programming. Our work is a first step in a non-easy journey, as it has been explained in the paper. The progress on the establishment of a sound quantum software engineering discipline will depend on how solid the foundations for managing the basic gears are. Without a doubt and from our point of view, a proper definition of quantum module is part of the solution.