## 7 Evaluation
### Discussion  
The experiment helped us to verify and validate the main conceptual ideas provided in this paper, particularly to prove that language processing technology can be successfully integrated into the M2M transformation solution. The results of the NLP-based processor were reasonable, indicating that almost 80% of target elements could be generated successfully, based on the results obtained using an experimental dataset composed of models from real-world business domains. However, the experiment itself also identified several issues that could be addressed in the future:  
* A limited set of bad naming practices, restricted to the most common ones (e.g., naming a use case using a single verb or noun), was considered. During the initial dataset screening, we observed many such cases. Identifying more cases of bad practices and introducing automated resolution of such cases into the developed solution could provide even better transformation results. * The use of non-alphanumeric symbols (e.g., dashes, commas, apostrophes) inside words also matters. It is advised to remove them from the model element names. While more advanced tokenizers should be able to handle many such cases, the risk of mishandling such cases remains. * Detection and resolution of abbreviations is also an actual issue. As stated in Section 7.1, they can be very context-dependent and may or may not be recognized as expected. Another similar issue is case sensitivity (e.g., \"US\" vs. \"us\"), as named entity recognizers can easily be confused. * Part-of-speech tagging can be sensitive to letter cases. While some modelers do prefer starting each word with a capital letter when naming activities, tasks, or use cases, some NLP tools may fail to tag them correctly (e.g., \"issue invoice\" could be tagged as \(<\)VERB\(><\)NOUN\(>\), but \"Issue Invoice\" might become \(<\)NOUN\(><\)NOUN\(>\), which would be an incorrect tagging result). During initial experimentation, we observed that some NLP tools, like Spacy, were quite sensitive to letter cases, which is also significant for practical application, as modeling practitioners tend to use proper or even mixed-case names. While such cases could be normalized to lowercase, doing so increases the risk that some features required for proper processing could be lost (e.g., recognition of named entities by the first uppercase letters). * Generally, using conjunctive/disjunctive clauses in element names is also considered as a bad modeling practice in modeling BPMN processes, UML use cases, or any other type of activity-like element, as they should be refactored to two or more elements. In our experiment, we considered that cases containing a single verb phrase and multiple noun phrases could be processed to generate multiple I\({}_{\text{IMCT}}\) output elements (e.g., \"assign manager and assistant\" can be processed as \"assign manager\" and \"assign assistant\"). Multiple verb phrases for the same subject could be processed similarly, provided the verb phrases are identified correctly (e.g., \"create and process invoice\" can be processed as \"create invoice\" and \"process invoice\"). However, having multiple candidate verb phrases and noun phrases leads to much more complex processing, which may require more advanced NLP techniques, such as dependency parsing. The same applies to cases where verb phrases, noun phrases, or both are separated by commas or other separator symbols (e.g., \"create, process, and manage invoice\"). This could be addressed in our further research. * There can be general ambiguity in detecting named entities and abbreviations. As stated in the previous section, there are numerous situations where entities cannot be processed correctly due to a lack of contextual information. Additional tools that take into account multiple features to improve precise meaning detection (e.g., context-based classifiers) could be applied to mitigate this problem and to correct extractor prediction.