# 3. Create cryptographic proof return zk_snark_proof
## 4 Use Case Study: OOM Metric Analyzer
#### Analysis of Obtained Results  
In this paper, the open-source software TextAdventure v1.0 was selected as a use case, primarily due to its modular architecture, the availability of its source code, and its moderate scale, which allowed for a comprehensive examination of various software metrics and an in-depth analysis of the system's maintainability, testability, comprehensibility, and reusability. The results of the software metric analysis contain the average values of various calculated metrics. Upon closer examination, it can be observed that one of the metrics--Cyclomatic Complexity per Method--is highlighted as problematic, even though its value falls within the recommended range, as shown in Table 1. This discrepancy arises because the recommended values in Table 1 refer to individual methods (or, in the case of other metrics, to individual classes). In addition to Cyclomatic Complexity, the Inheritance Coupling metric indicates that the values of certain classes exceed the recommended limits. This parameter, along with the Depth of Inheritance Tree and Number of Children metrics, suggests that the level of inheritance in the analyzed software is not particularly deep, which can be beneficial for architectural simplicity. Software metrics related to class cohesion--specifically LCOM1 and LCOM4--are particularly concerning. As shown in Table 1, the recommended value for LCOM1 is 0. Based on this, it can be concluded that some classes contain methods that are not functionally related, which may lead to poor modularity and maintenance difficulties. Another issue identified in the analyzed software is highlighted by the LCOM4 metric, which suggests that certain classes could be split into smaller ones to improve cohesion and maintainability. The MIF (Method Inheritance Factor) metric, which represents the ratio of inherited methods in a class to the total number of available methods, is moderately elevated, indicating moderate use of inheritance. This may be beneficial in terms of code reuse and structural organization, contributing to maintainability and consistency within the software architecture. Metrics that indicate class and method coupling are also slightly elevated, suggesting that some classes are overly dependent on others within the system. A high degree of coupling can lead to poor structural isolation and increased sensitivity to modifications, making the system more difficult to maintain and extend. Despite the majority of software quality metrics falling within acceptable thresholds, five key indicators in our case study--**LOC, IC, LCOM1, LCOM4**, and **AIF**--failed validation. These violations signaled architectural and design inefficiencies that could affect long-term maintainability, testability, and modular reuse. \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Metric Name**} & **Current** & \multirow{2}{*}{**Threshold**} & \multirow{2}{*}{**Validation**} & **Required Refactoring** \\  & **Value** & & & **Action** \\ \hline Lines of Code (LOC) & 600 & \(\leq\)500 & Invalid & Decomposes into smaller, functionally cohesive units \\ Inheritance Coupling (IC) & 3–5 & \(\leq\)0.5 & Invalid & Reduces dependence on inherited members \\ Lack of Cohesion (LCOM1) & \(<\)5 & \(\leq\)2.5 & Invalid & Groups related behaviors and remove unrelated logic \\ Lack of Cohesion (LCOM4) & 5–15 & \(\leq\)1.0 & Invalid & Improves internal method interaction \\ Attribute Inheritance Factor (AIF) & 0–2 & \(\geq\)0.5 & Invalid & Increases reuse of inherited attributes \\ All other metrics & Within & \multirow{2}{*}{/} & \multirow{2}{*}{Valid} & \multirow{2}{*}{/} \\  & threshold & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Validation results. The high **LOC** count indicates that the class was overly large and likely violated the single-responsibility principle. Splitting the codebase into more focused components improved both maintainability and readability.