## 5 Discussion
This is where domain-specific visual representations become useful, embedding meaningful information into a concise, semantically-valid notation. Specifically, the PROVE representation (Figure 13) was estimated as more effective in communicating and modeling DPD (compared with the more cumbersome OPM representation to which it maps uniquely), based on the representational elements number metric; and is, therefore, a better frontend for a DPD practitioner. This reduction of representational elements when using PROVE (as a DSM) compared with OPM (as a GSM) confirms our second hypothesis. The two underlying models are equivalent, and a model-to-model transformation can be exercised to transform one model into the other. Alternately, the PROVE representation can be used on top of OPM modeling infrastructure, i.e., serving as a frontend to an OPM information model. Our use of specialized, domain-specific language and representation as a complementary tool to OPM addresses an explicit suggestion for future research (in the conclusions of a recent effort that explores the use of another engineering tool--the design structure matrix--to improve OPM models) [13]. While we noted similar tactics of using reduction and representation in modeling, we did not encounter any reflective generalization and theory building based on these practicalities, as we provided here. We discuss two recent examples. (1) The MBSE tool Capella has recently underwent a decrease in the construct redundancy of its underlying model by unifying two basic constructs--\"Actor\" and \"Component\"--to a single construct (\"Component\"), while supporting multiple representations based on associated attributes [45]. This was reportedly done due to practicalities and better understanding of modeling use-cases, both implicitly relate to domain ontology. (2) In their introduction of the Privacy-Enhanced BPMN model, [PERSON] et al. did not explore the BPMN specification as a rigorous modeling methodology; however, they specifically identified the need to restrict usage of BPMN elements before developing extensions to the standard [46]. Their reduction was done to avoid redundant elements. This implicitly demonstrated that limiting a general-purpose language is a useful technique for its domain-specific application. Whereas GPM may be fit for meta-modeling and for the computerized realization of models, they are insufficient for the effective and rigorous application of MBSE. Domain-specific ontologies and representations facilitate rigorous and approachable modeling; while a supporting modeling infrastructure can map the domain-specific representations to a digital model that is compliant with the GPM, e.g., for promoting the interoperability of models and supporting the integration between multiple domain-specific models into a single, multi-domain information model. This is important as it keeps the process designer focused on aspects of the domain (in DPD: process design) and not of modeling; consequently, it may facilitate MBSE adoption by domain practitioners who are not familiar with digital modeling technicalities. [PERSON] et al. [47] demonstrated a similar approach in their transformation of an Extended Actigram Star diagram (and model) into a BPMN model; yet they did not provide a detailed, comparative analysis with respect to the technical and cognitive modeling effort of producing the different models, let alone provide any objective metrics (such as the two metrics we established, as discussed shortly). Further research may continue to explore the reciprocation between GPM and DSM in various domains to unveil modeling guidelines and contexts for using both, separately and jointly. Our demonstration relies on extensive experience with modeling in both academia and industry. Our research is designed as a generalized single case study, and therefore may be of limited context.