Contents for a Model-Based Software Engineering Body of Knowledge

Although Model-Based Software Engineering (MBE) is a widely accepted Software Engineering (SE) discipline, no agreed-upon core set of concepts and practices (i.e., a Body of Knowledge) has been defined for it yet. With the goals of characterizing the contents of the MBE discipline, promoting a global consistent view of it, clarifying its scope with regard to other SE disciplines, and defining a foundation for the development of educational curricula on MBE, this paper proposes the contents for a Body of Knowledge for MBE. We also describe the methodology that we have used to come up with the proposed list of contents, as well as the results of a survey study that we conducted to sound out the opinion of the community on the importance of the proposed topics and their level of coverage in the existing SE curricula.


Introduction
Model-Based Software Engineering (MBE) is a widely accepted Software Engineering (SE) discipline that promotes the use of models and model transformations as the fundamental elements of software development [5]. With almost 20 years of existence [3,18], MBE is already part of most SE curricula, and the industrial use of its concepts and practices keeps growing. 1 Despite its expanding adoption in industry and academia, no widely agreed-upon core set of concepts, elements and practices encompassed by MBE has been described anywhere yet. Such a compendium corresponds to the notion of a "Body of Knowledge" (BoK) used in many engineering disciplines, which comprises the set of concepts, terms, and activities that make up a professional domain, being a fundamental part of any profession [15].
In 2018, we started working on the basic contents of a BoK for MBE (hereinafter, MBEBOK), with the goals of characterizing the contents of the MBE discipline, promoting a consistent view of it worldwide, clarifying its scope with regard to other SE disciplines, and defining a foundation for the development of MBE curricula. As part of this effort, a set of topics was identified and presented at the MODELS 2018 Educators' Symposium [7], where we received useful feedback not only about the topics themselves, but also on how to potentially implement the MBEBOK.
After the symposium, we decided to validate the revised list of topics with the MBE community by means of conducting a survey to obtain a clear picture about: (a) the importance that the community gives to each topic in education and certification of model-based software engineers; (b) the coverage of these topics in current SE/MBE curricula, at both Bachelor and Master levels.
The response from the community was significant (101 answers), and the results of the survey provide an interesting snapshot of the current situation. This paper presents these results and formulates a proposal of the topics that should form an MBEBOK. The long-term goal for the MBEBOK is to significantly help consolidate the field of MBE as well as to improve the way it is currently taught and practiced. Our proposal also aims at providing the basis upon which an extension of the Guide to the Software Engineering BoK (SWE-BOK) can be developed to entail all aspects related to MBE.
The paper is structured in Sect. 5. After this introduction, Sect. 2 discusses what a Body of Knowledge is and 1 Note that although an apparently more natural acronym for Model-Based Software Engineering would have been "MBSE," we opted instead for MBE to mitigate potential misunderstandings with other initiatives, especially from industrial research and practice. A glaring example is the International Council on Systems Engineering (INCOSE) initiative, which has defined "MBSE" as the standard acronym for Model-Based Systems Engineering widely used in industry [11], as also reported by the Systems Engineering Body of Knowledge (SEBOK) [1]. briefly presents some of them related to Software, in particular the SWEBOK. Then, Sect. 3 identifies the basic topics that should form part of contents of the MBEBOK, as well as the methodology we have followed to develop it. Finally, Sect. 4 discusses some issues related to the proposal, and Sect. 5 concludes the paper and outlines the next steps.

Bodies of Knowledge
A Body of Knowledge (BoK) is a set of concepts, terminology, and tasks that constitute a professional domain. Often, a BoK is developed by a professional association (e.g., ACM, IEEE) and captures the knowledge that is inherent, sometimes tacit, and often explicit in the interactions and literature that occur in that professional domain. The main goals of a BoK on a given discipline are: -to promote a consistent and global view of the discipline; -to specify the scope of the discipline and to clarify its place with respect to other related disciplines; -to characterize the contents, and known practices of the discipline, organizing them in a coherent and comprehensive manner; -to provide a foundation for curriculum development and, when applicable, for individual certification and licensing material.
A BoK should also provide concrete deliverables, more specifically: -A terminology that defines the set of main concepts of the discipline, as used by their practitioners; this constitutes the accepted ontology for the specific domain. -A structured list of the main Knowledge Areas, skills and accepted practices of the discipline, covering all the basic knowledge that any practitioner should possess.
A BoK should always be descriptive, but not prescriptive: Intentionally, it should not impose any particular method or tool, nor specific practices.
With respect to what should be considered as "generally recognized" or as a "good practice" of a discipline, the Project Management BoK (PMBOK) [16] offers precise definitions. First, "generally recognized" means that the knowledge and practices described are generally applicable to multiple kinds of diversified projects in various situations, and there is consensus about their value and usefulness. In turn, "good practice" means that there is general agreement that the application of skills, tools, and techniques can enhance the chances of success over a wide range of projects.
It does not mean, however, that the precise knowledge or practice should always be applied to any project; the organization and/or project management team should ultimately be responsible for determining what practices are more appropriate for a given project in a certain situation.
Currently, there are a number of BoKs for various software-related disciplines; some are mature documents with a rigorous review and revision process (e.g., SWEBOK), while others are evolving (e.g., SLEBOK):

The Software Engineering BoK (SWEBOK)
In 2004, the IEEE Computer Society established for the first time a baseline for the BoK of the field of software engineering. It was the outcome of a joint effort with ACM, whose mission was "to establish the appropriate set(s) of criteria and norms for professional practice of software engineering upon which industrial decisions, professional certification, and educational curricula can be based." The SWEBOK was developed as an international collective effort, in order to achieve the goal of providing a consistent global view of software engineering. The committee appointed two chief editors, several co-editors to support them, and editors for each of the Knowledge Areas. All chapters were openly reviewed, in an editing process that engaged approximately 150 reviewers from 33 countries. Professional and scientific societies, as well as public agencies from all over the world involved in software engineering, were contacted, made aware of this project, and invited to participate in the review process too. Presentations on the project were made at various international venues. The 2004 edition was revised in 2014, using the same editing process, giving birth in 2014 to the current version (v3) of the SWEBOK [4]. The SWEBOK has been adopted by ISO and IEC as ISO/IEC TR 19759:2005. 2 It should be noted that the SWEBOK does not aim at describing the entire BoK for software engineering. Instead, it provides a "guide" to the existing BoK that has been developed since the start of the discipline-generally agreed to have happened in 1964, in the NATO conference held in Germany to discuss, for the first time, the software crisis.  One complete KA of the SWEBOK is devoted to Software Engineering Models and Methods (Chapter 9). As stated in the SWEBOK, software engineering models and methods impose structure on software engineering with the goal of making that activity systematic, repeatable, and ultimately more success-oriented. The use of models provides an approach to problem solving, a notation, and procedures for model construction and analysis. Methods provide an approach to the systematic specification, design, construction, test, and verification of the end-item software and associated work products. Figure 1 shows the breakdown of topics for the SE Models and Methods Knowledge Area (Chapter 9): -Modeling: It discusses the general practice of modeling, and presents: -The basic modeling concepts and principles -Properties (such as completeness, consistency, and correctness) and expression of models (as typed and attributed elements representing entities, and associations representing relationships among them, using graphical or textual notations) -Syntax, Semantics, and Pragmatics of models -Preconditions, postconditions, and invariants as specification mechanisms -Type of models: It briefly discusses models and aggregation of submodels and provides some general characteristics of model types commonly found in the software engineering practice, including: -Information models (a.k.a. conceptual models) -Behavior models (state machines, control-flow models, dataflow models) -Structure models (e.g., UML class, component, object, deployment, and packaging diagrams) -Analysis of models: It presents some of the common analysis techniques used in modeling to verify completeness, consistency, correctness, traceability, and interaction analysis. -Software Engineering Methods: It presents a brief summary of commonly used software engineering methods, including heuristic methods, formal methods, prototyping, and agile methods. This part is more general and aims to apply to any SE discipline, not only to MBE.
In addition to these topics, the SWEBOK lists the International Standards related to "Software Engineering Models and Methods" in its Annex B. There are three groups of standards, depending on their scope: modeling notations (such as IDEF, UML, OCL, or KDM); tools (IEEE Stds. 14102, 14471, and 1175, which apply to all CASE tools and their interoperability); and the environments of the systems (such as ISO/IEC 26515, on developing information in agile environments, and 15940 on Software Engineering environment services). One additional standard about terminology (ISO/IEC 24765) is common to all Knowledge Areas. By looking at the concepts and related standards, we see that the coverage of MBE concepts and mechanisms is generally appropriate, but some essential concepts of MBE that should be part of the education of MBE practitionerssuch as model transformations, executable models, or code generation, for instance-have not been included. Furthermore, although the SWEBOK provides definitions for some MBE concepts, not all of them are precisely defined, and in some cases the given definitions miss important features and characteristics of the defined concepts that have been later identified by the modeling community. In this respect, providing precise definitions for all the main MBE terms is another goal of the MBEBOK.

Software Language Engineering BoK (SLEBOK)
The field of Software Language Engineering (SLE) has emerged to connect and integrate different research disciplines such as compiler construction, reverse engineering, software transformation, model-driven engineering, and ontologies, in order to identify the principles and practices of engineering software languages-i.e., languages that may ultimately be implemented on a machine. SLEBOK is an ongoing initiative to capture a BoK for SLE. A Dagstuhl seminar [8] was held to capture a preliminary set of artifacts, definitions, methods, best practices, open challenges, etc. The intent was for these to be consolidated into the SLEBOK, which is currently evolving. While SWEBOK and several other BoKs have a mature process for their continued evolution and development, SLEBOK does not yet have such a process. However, SLEBOK is noteworthy in the fact that it is very open, and anyone can contribute to the revision process via its Git repository [19].
MBE principles and techniques can be used for Software Language Engineering (e.g., metamodels can be used to define the abstract syntax of software languages). As such, there are relationships between SLEBOK and MBEBOK. Although these relationships are still evolving, due to the relative immaturity of both BoKs, we can make some key observations: -SLEBOK defines notions of model and metamodel which are not incompatible with MBEBOK, though MBE-BOK's definitions are more elaborated [7]. -SLEBOK does mention the notion of static semantics, but does not elaborate on language semantics, whereas MBEBOK explicitly captures model semantics as a key concept. -SLEBOK and MBEBOK treat abstract and concrete syntax differently; while these are first-class concepts in MBEBOK, their notions are distributed across multiple concepts in SLEBOK.

Developing the proposed list of topics
The list of topics proposed for the contents of the MBEBOK is shown in Figs. 2 and 3. This list was produced in two stages. An initial proposal was presented at the MODELS Educators' Symposium in October 2018 and discussed during the event with the audience. A poster with the proposal was also prepared and displayed during the conference, and the participants were asked to comment on its contents. Apart from the suggestions made directly to the poster presenters, sticky notes and pens were available for attendees to annotate the poster with comments at any time during the three days of the conference. A shared document was also available online after the conference so that any interested person could comment on it. We received numerous interesting and valuable comments and suggestions and refined the list of topics in November 2018. The next step was to reach the wider modeling audience to get a feedback from the interested community. For this, we decided to conduct a survey study. A questionnaire was developed to sound out the opinion of the community about three main aspects: the topics included in the list, the importance assigned to each of them, and the coverage of the topics in the courses taught at the respondents' institutions, at both Bachelor and Master levels. The outcomes are summarized in the following sections and depicted in Figs. 2, 3, and 4.

List of topics
The proposed list contains the topics that were considered to be relevant for the MBEBOK, i.e., that should be part of the knowledge that any MBE practitioner should possess. The list proposed in the survey, which is shown in the first column of Figs. 2 and 3, is structured into the following nine sections.

The survey
The survey 3 was conducted in December 2018. An invitation to participate was sent to all major Software Engineering and Modeling distribution lists, with a questionnaire where participants were asked to grade their perceived importance for each topic and whether the topic was covered in any of the courses taught at their institution. The detailed instructions given to the participants were the following: "By assigning importance to each topic, you are defining the minimum set of concepts that an average MBS engi-3 https://encuestas.uma.es/27511/lang-en.

neer should know, according to your own view of what an 'average' model-based software engineer is. In the questions below, 'Not important at all' means that this topic should not be part of the basic curriculum. "Covered" means that the topic is already covered in any of the courses taught at your institution, at Bachelor or Master level, or both. Respond indicating the level of coverage of the topic in the course(s)."
A 4-point Likert scale was used to record the importance assigned to each topic: (1) "Not at all important," (2) "Slightly important," (3) "Moderately important," and (4) "Important." An additional option "No opinion" was also included. Similarly, coverage was captured by a 4-value Likert scale: (1) "No,' (2) "Slightly," (3) "Enough," and (4) "Well," with an additional value "Do not know" to improve the reliability of the responses.
A total of 101 responses were recorded, from 23 different countries, distributed across continents as follows: Europe 85%, America 11%, Oceania 2%, Asia 1%, and Africa 1%. The results of the survey, including the raw responses from the participants, are available at http://bit. ly/MBEBOK-2018SurveyResults. Figures 2 and 3 display the results in tabular form. Each row represents a specific topic, with the average score and standard deviation of the assigned importance and coverage at BSc and MSc levels. The last two columns show the difference between the importance assigned to a topic and how it is covered in the curricula of the institution, in order to identify possible decompensations. Cells shaded in green color highlight the highest scores, while red-shaded cells identify the lowest. The highest standard deviations are highlighted in yellow; they identify the topics with less consensus.
For clarity, Fig. 4 shows the results of the survey graphically. The X-axis lists the topics (they are the same as those listed in Figs. 2 and 3, respectively), while the Y-axis plots the resulting scores of the answers: topic importance and topic coverage at MSc and BSc levels.

Main findings
The results of the survey provided a very interesting feedback about our proposed list of topics. • Low score in Importance (this indicates lack of support): -Score below 2.5: Animation (5.5), Streaming Transformations (9.2.1) -Score below 2.75: Further topics (9.2), Incremental Transformations (9.2.2), Uncertainty (9.2.3) • No Opinion (this normally indicates lack of sufficient knowledge about the topic): -Between 10% and 15%: Streaming Transformations (9.2.1); -More than 15%: Physics of notations (5.2) (b) Topics with low coverage. Interestingly, there is a clear correlation between importance and coverage: In general, more important topics show higher coverage in existing curricula (the Pearson coefficient for the correlation between the assigned importance and the coverage at BSc level is 0.73 and 0.82 for the coverage at MSc level). There are significant exceptions, such as model maintenance and execution; despite being considered fairly important, their coverage is rather low. (c) Relative importance of subtopics. There are some topicsnamely 3.1 (structural model analysis), 8.1 (model transformation languages), and 9.1 (MBE application domains)classified as Basic due to their importance, but the selected subtopics are, however, classified as Intermediate or even Advanced. This means that the topic as a whole is considered essential, but the subtopics themselves are slightly less relevant. (d) Teaching metamodels and grammars. There seems to be a discrepancy in the community about when to teach metamodels and grammars, whether at BSc or MSc levels. This issue would require further analyses.

Proposal
After analyzing the results of the survey, our proposal is summarized in the last column of the tables shown in Figs. 2 and 3, where we have classified each topic as: Basic, Intermediate, or Advanced. Topics marked with two hyphens (--) received little support, and hence, they have been excluded from the final proposal.
Topics were classified as Basic if their average importance score was above 3.45, and Intermediate if importance was above 3.0, which represent, respectively, an average of 86% and 66% of the max score in the Likert scale [1][2][3][4]. Advanced topics were those that scored at least 2.8 in importance (60%). We decided to discard those topics that did not reach a score of 2.8 in importance or did not get sufficient support, as discussed above. This classification is also consistent with the expected coverage of each topic at BSc and MSc levels. Basic topics should be taught at BSc level.
Basic and Intermediate topics should be covered by all BSc and MSc courses on MBE. This approach would provide the required homogeneity and interoperability between the foundational contents of separate MBE curricula.
Advanced topics could be either covered at MSc level or as part of specialized courses, depending on the educational institution. In this way, each institution could define specialized offerings depending on the knowledge and experience of its research groups. However, they all will be able to share the same core concepts, use the same terminology, and have a common background in the basic MBE courses.
Of course, additional MBE topics (e.g., those not included in the list) could also be taught depending on the experience, industrial demands, and specialized offerings of each institution.

Integration with the SWEBOK
As mentioned earlier, the SWEBOK already provides good coverage of some of the concepts and practices of MBE. However, it misses out some key elements that should be part of the knowledge and skills of any model-based software engineer.
At the beginning of this effort, we considered several options to integrate our extension with the contents of the SWEBOK, from more conservative to more disruptive: (a) adding paragraphs to the existing text of Chapter 9 and new subsections if needed, but respecting its current structure; (b) replacing the contents of the entire Chapter 9; and (c) creating a complete BoK, separating from SWEBOK (this is the strategy that other BoKs, e.g., SLEBOK, adopted).
Based on the suggestions received at EduSymp'18, our proposal is to follow the same strategy as other extensions to BoKs, which are delivered as Appendices to them. Such a strategy is not intrusive nor disruptive and enables both the SWEBOK and the MBE-annex to separately evolve, but still maintaining consistency and minimizing redundancy.

Integration with the SLEBOK
The design, development, and maintenance of modeling languages could be considered as very important for any MBE practitioner. In fact, a number of topics listed in Sect. 3 already cover several aspects related to Software Language Engineering that apply to modeling languages. Although in theory the SLEBOK should address most of these topics, by looking at its current contents it does not seem to cover some MBE topics adequately. For example, simple topics such as syntax and semantics are not covered in their generality, or at least with not enough level of detail for our purposes.
Similarly to what we are proposing here with the SWE-BOK, the relationship between the MBEBOK and the SLEBOK should be clarified, stating the scopes of both BoKs, identifying their intersecting concepts and mechanisms, and making sure that they are treated consistently in both guides. This is not a trivial issue, given the current status of the SLEBOK. However, the fact that it is still under development can also be an advantage: now that we have identified the topics that should be part of the MBEBOK, it would be a matter of defining an integration strategy that permits complementing the contents of both BoKs in a successful manner.

Relationships with other BoKs
Although the closest connections of the MBEBOK are with the SWEBOK and the SLEBOK, overlaps with the other BoKs listed in Sect. 2.1 also exist. The identification and analysis of common and related topics with other BoKs is essential in order to maintain consistency and interoperability with the rest of the engineering disciplines.

Field studies and other related initiatives
In parallel with the development of the basic contents for the MBEBOK, a number of ongoing initiatives are surveying different aspects of how models are currently taught, for example, the experiences of instructors when teaching modeling and MBE topics [6] or the experiences of students with software modeling tools [2]. These initiatives nicely complement our present proposal and could be of significant value for the development of the Guide to the MBEBOK, e.g., to define the MBE skills and practices required to use the concepts identified in this work, and the kinds of tools needed by MBE practitioners and students.

Conclusions and next steps
This paper has presented a proposal for the list of topics that should be covered by the MBEBOK. As such, it aims to characterize the contents and known practices of the MBE discipline, assist universities and other institutions that provide teaching courses on SE to develop their MBE curricula, and identify the core set of concepts that any MBE engineer should know, providing a common and consistent reference terminology. We are convinced that this will significantly help to consolidate the field of MBE, clarify its scope with respect to other SE disciplines, and to improve the way it is currently taught.
Based on this proposal, we now plan to start working on "the Guide to the MBE Body of Knowledge," which further develops these concepts and the practices that support the discipline. Such a document is intended to supplement the contents of the SWEBOK and to be aligned with the current SLEBOK efforts and with the rest of the engineering BoKs.
Our effort will continue in two main directions. First, part of us will be in charge of developing the "Guide to the MBE-BOK" as an Annex to the SWEBOK. A smaller group of experts will work on the glossary of terms for the MBE-BOK, too. Once initial versions of the Guide and of the Glossary will be ready, we will let them circulate it to a broader audience so that the SE, MBE, and SLE communities have the opportunity to revise them and provide suggestions. We envision the first version of the MBEBOK as an open and collaborative platform (e.g., GitBook) that will be used to (i) disseminate the MBEBOK while writing it and (ii) continue to collect feedback from the community.
In this respect, we would like to use the opportunity to invite educators and researchers of the SoSyM community willing to contribute to this effort. Volunteers ready to participate are invited to write to us, indicating how they want and can help, to the following mail address: TheMBE-BOK@gmail.com.
Gabriele Taentzer is professor in software engineering at the Philipps-Universität Marburg. Her research interests include formal foundations and applications of model-driven software engineering, graph transformation, and software quality assurance. Contact her at taentzer@informatik. uni-marburg.de, or visit www.unimarburg.de/fb12/swt.