# 3. Create cryptographic proof return zk_snark_proof
## 4 Use Case Study: OOM Metric Analyzer
#### Analysis of Obtained Results
The **Inheritance Coupling (IC)** suggested that the class relied too heavily on inherited structures, which can obscure control flow and reduce understandability--especially in Python, where dynamic method resolution can exacerbate these issues. The **LCOM1** and **LCOM4** metrics pointed to poor cohesion, with methods possibly grouped arbitrarily rather than centered around shared data or functionality. Modularization or redistribution of functionality across logical units were advised. Finally, the **low AIF** value revealed that attributes inherited from parent classes are being underutilized. This indicates that subclassing was syntactically present but semantically redundant. To ensure a valid submission under BMVS-ZKP*, the following targeted values should be achieved post-refactoring (Table 3):  
To satisfy the constraints defined in the BMVS-ZKP* validation scheme, the original Python class underwent a targeted refactoring process. The primary goal was to address five specific metrics that failed the predefined thresholds: **Lines of Code (LOC), Inheritance Coupling (IC), Lack of Cohesion (LCOM1 and LCOM4)**, and **Attribute Inheritance Factor (AIF)**. Each of these indicators played a critical role in determining the class's modularity, reusability, and structural clarity. The initial LOC of the class exceeded 600, which suggested an overly large and potentially monolithic design. To address this, the class was **decomposed into multiple smaller, logically cohesive units**. Unrelated methods were extracted into helper classes, and redundant blocks were replaced with utility functions. These changes led to a leaner design, bringing the LOC under the 500-line threshold. This not only improved readability but also enhanced maintainability and reduced testing complexity. An IC score of 0.69 indicated excessive reliance on inherited methods and attributes. Refactoring strategies focused **on replacing deep inheritance with composition**, thereby promoting flexibility and modularity. Classes were redesigned to depend on clearly defined interfaces rather than implicit superclass behavior. This shift reduced the IC value below the threshold of 0.5, resulting in a more robust and loosely coupled architecture. The cohesion metrics revealed fragmentation in the class's internal logic, with LCOM1 at 5.88 and LCOM4 exceeding the acceptable range. To resolve this, methods were **grouped based on their interaction with shared class attributes**, and responsibilities were re-distributed among new subclasses. This modular restructuring significantly improved cohesion, reducing LCOM1 to below 2.0 and LCOM4 to within the optimal 1.0 range. As a result, the class became more focused in purpose and easier to understand and maintain. The AIF score of 0.38 suggested that the class was underutilizing attributes defined in its parent classes. The refactoring process emphasized **promoting attribute reuse** by consolidating common fields in base classes and eliminating redundant variable declarations \begin{table}
\begin{tabular}{c c c} \hline \hline
**Metric Name** & **Target Value** & **Justification** \\ \hline Lines of Code (LOC) & \(\leq\)500 & Reduces complexity and improves maintainability \\ Inheritance Coupling (IC) & \(\leq\)0.50 & Ensures minimal tight coupling with base classes \\ Lack of Cohesion (LCOM1) & \(\leq\)2.0 & Improves class cohesion and functional clarity \\ Lack of Cohesion (LCOM4) & \(\leq\)1.0 & Ensures meaningful interaction among methods \\ Attribute Inheritance Factor (AIF) & \(\geq\)0.5 & Promotes effective attribute reuse via inheritance \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Target values for validation. in subclasses. These efforts elevated the AIF to above 0.5, reinforcing the semantic value of the inheritance hierarchy and ensuring more effective reuse of object state.