## 3 Dataset Construction
### Validation of Dataset Validity  
When manually constructing a dataset, verifying the integrity and consistency of the data is an essential step to ensure that no critical information is missing from the dataset. At the same time, it is ensured that the data remain logically consistent among the various parts, thus providing a solid foundation for subsequent data processing and analysis, and effectively preventing the distortion of results due to missing or self-contradictory data. This results in the need for data integrity and consistency validation [41]. Data integrity validation is the process of checking whether the data are comprehensive and free of omissions, whether the data are unique or redundant, and ensuring that the data have not been tampered with or corrupted during transmission or storage. Data integrity validation helps identify and correct incomplete or redundant parts of the data in a timely manner, thus ensuring that data-based decision making and analysis are reliable and effective. Dataconsistency validation is the process of primarily checking for discrepancies or conflicts between data from different data sources or different points in time and ensuring that they remain consistent across systems. As described in Section 4.1, for text-based contextual datasets and candidate word sets, the steps of preprocessing and cleaning the data have already been experienced during their construction. Therefore, the focus of this section is on validating the SysML dataset. In order to ensure that the constructed model accurately reflects the actual requirements and design of the system, and to prevent model bias due to missing or incorrect data, the integrity and accuracy of the data are verified after manually constructing the SysML model dataset, which in turn ensures the validity and reliability of the analysis and decision making based on this dataset. Since the models are completed in different project contexts, Project1 and Project2 each define the model elements therein, the following possible contradictions need to be considered when merging the model data:  
1. Whether there is a concept of duplication of model elements across projects;
2. Whether the model elements across projects have different definitions for the same concepts;
3. Whether the model elements across projects have a circular inheritance relationship;
4. Whether model elements across projects have the same combination of relationships and pairs of relationships. Based on the result of parsing the XML file, data validation is performed based on each node and its contextual information. For the above problems, different methods are used in turn to solve them:  
1. Iterate over the node names in all projects and query whether there is any duplication;
2. Iterate over the node names in all projects, and if there are nodes with the same name, compare their contextual information, including the father node, child nodes and attribute values;
3. Traverses all parent-child pairs in the project, performs depth-first search based on the concept of stack [42], and detects circular dependencies by maintaining access lists and path lists. The access list is used to record the nodes that have been checked and have no problems, while the path list is used to record the nodes in the current search path so that the specific path can be pointed out when a circular dependency is detected;
4. Iterate through all the parent-child pairs in the project and query for the existence of duplicate parent-child pairs. By using the above method, the model data were examined and it was found that there were classes with the same name in both projects, but not classes with the same context. This situation occurs because the class was designed in a different context, so the design perspectives are different. Iterating through all the parent-child pairs in the projects, no circular dependency issues were found, but duplicate parent-child pairs were found.