## 2 Background  
### Model-Based Systems Engineering (MBSE)  
MBSE is \"the formalized application of modeling principles, methods, languages, and tools to the entire lifecycle of large, complex, interdisciplinary, sociotechnical systems\" [1]. MBSE is regarded as an approach to address the increasing complexity of systems in general and the complexity of their development, specifically. Some of the main features of MBSE identified as beneficial are enhancing communication between stakeholders; establishing shared understanding of relevant domains; and improving the capture and reuse of knowledge and information. Accordingly, MBSE can be viewed as a distributed cognition mechanism, allowing rigorous design and analysis of large amounts of data, using visual representations and common data repositories--established and maintained by relevant stakeholders--as a coherent, unambiguous digital model [1; 26]. In a recent survey, the majority of participating practitioners credited improvement across almost all systems engineering tasks to the use of MBSE [5]. In general, MBSE solutions comprise two core components: (1) a methodology, providing the formal aspects of the model to be used as well as modeling concepts, methods, and a language; and (2) a software-based modeling tool implementing the methodology. While the essentials of MBSE are beyond the scope of this paper, we provide a brief introduction herein, and further discuss relevant aspects of MBSE throughout the paper, whenever required. A modeling methodology may include concepts, methods, and a language--alternately, a notation or a representation. The concept and methods detail how to build a digital information model; while a modeling language dictates the representation of the model, typically using visual elements and their relationships as syntax. In what follows, we use the term methodology to refer to one or more of its constituents. [PERSON] emphasized four characteristics of models [27]: (1) they consist of a set of assumptions about some system; (2) they attribute mechanisms to the system, meant to explain exhibited properties; (3) they are an approximation useful for certain purposes; and (4) they are often developed on the basis of analogies between the represented system and some different system. In addition, the Bunge-Wand-Weber model stresses the importance of the ontological clarity of modeling language constructs, i.e., the clear association of a language construct with an ontological construct [28]. A practical methodology, therefore, is expected to refer to the relevant domain's ontology (see, for example, [29]). Domain ontologies are considered important in defining and coordinating terminologies, concepts, and their relationships as well as in facilitating consistency and interoperability between different applications; and their effective use requires a well-designed language [12; 30]. However, this is not always the case. [PERSON] and [PERSON] [31] identified that modeling language constructs are typically first created to represent software elements and not real-world elements; and called for assigning ontological meaning to modeling constructs. Specifically, [PERSON] asserted that the prominent Unified Modeling Language (UML) \"is designed for software developers, not for end users\" [32]. He also identified the mapping of system-oriented constructs of GPM languages to user-oriented and process-oriented concepts as a core challenge to which no general solution exists; and attributed the lack of a standardized approach to the wide range of process modeling approaches. Similarly, [PERSON] et al. noted the absence of complete and consistent modeling specifications as a cause for the limited use and acceptance of modeling languages, as well as for the idiosyncratic nature of resulting models (which, in turn, reduces their comprehensibility and their reusability) [33]. In their survey of modeling language specifications, [PERSON] et al. found that almost all the specifications use redundant notations.