Modeling should be an independent scientific discipline

When you believe that everything is a model [5] you see models everywhere. Especially when having a broad view of what constitutes a model and the different types of models that exist [16], and not only in computer science.¹ In fact, modeling is as old as mankind itself² because it has always allowed humans to represent reality in order to communicate, understand how something works, and devise and build more complex artifacts and systems.

To illustrate this omnipresence of modeling, we give examples of the use of modeling in different fields, starting with our own (software) and broadening more and more the scope of modeling applications.

The key role of abstraction and modeling in software engineering and computer science in general has been widely acknowledged [2, 20, 28]. As a recent example of this, it is worth mentioning the growing number of AI solutions that are becoming model-based.³ As in any other field, once the core components of the AI technology have been established, the effort moves to facilitate their use and adoption by a larger user base, and this always involves moving up the abstraction ladder and creating model-based solutions that require less technical expertise to reach the same result.

This key role of modeling also holds if we go beyond computer science. This is obvious when we look at systems engineering, where models are massively used (probably even more than in software engineering itself) for verification and simulation purposes. The growing importance of digital twins, which are model-based by definition [19], is a clear example. It is also easy to find examples in other engineering disciplines, e.g., plant-wide models for water resource recovery facilities [27], or of a moving crane [32].

Models are also widely used in science. From climate modeling [17] to epidemiology modeling [9] and going through farming modeling,⁴ healthcare⁵ or core cellular biological function [14], we can easily find plenty of examples of models of different shape, type and function in the scientific literature.

Last but not least, citizens are also exposed to numerous models in their daily life. City and transport maps, workflow models and hierarchical models commonly used in any company are three examples of that.

All these models provide representations of systems. It is important to realize that all models, not only the biological, mathematical or engineering models, but also those commonly used in our daily lives, are of different natures but share a set of common characteristics. First, a conceptual model consists of concepts used to help people know, understand, or simulate the system that the model represents. Second, models are expressed using a concrete and precise notation, let it be mathematical equations, abstract symbols or a dedicated textual language (concrete syntax). Third, a model has a semantics that permits interpreting its symbols in a precise and unambiguous manner. Finally, models count on an inference system that allows reasoning about the estimated or desired behavior of the system being represented.

Even if modeling is everywhere, we believe software modeling has some particularities that make it especially useful as one of the pillars of the new modeling discipline we propose in the next sections.

Software engineering models have been very good at identifying and formally defining all model characteristics, and providing valuable tool support for them. For example, metamodels are used to define the abstract syntax of models at the appropriate level of abstraction, in terms of their concepts, the relationships between them, and the corresponding well-formed constraints of the modeled domain. Then, concrete syntaxes define the notations used to represent the concepts, and we already count on useful tools to generate powerful model editors and other model management operations: comparison, instance generation, satisfiability, etc. Semantics is commonly defined in software engineering in terms of mappings to domains with well-defined semantics, whose inference systems are used to reason about the source models, and where the reasoning tools available in the target domains can be used by the source models.

Compared to the models used in other domains, we can see how software engineering has been able to provide a formal background and mature tools to define, develop, manage and reason about models at the right level of abstraction. Other valuable contributions of software engineering to conceptual modeling are the automated processing of models, as well as the interoperability of tools and the seamless exchange and sharing of models.

Going back to the examples mentioned above, some engineering or biological models and tools are very powerful for simulating physical systems, but their definition mechanisms remain at a very low level of abstraction and do not support high-level abstraction mechanisms such as inheritance, polymorphism or modularity. In addition, most of these models and tools live in silos that do not allow for seamless model interchange or tool combination. These are precisely the types of support that model-based software engineering can provide. In turn, the application of software modeling mechanisms and tools to these domains can help to validate and significantly improve these mechanisms and tools, uncover some of their limitations, broaden their scope and open up new challenges.

If you ask software practitioners, they will typically equate modeling to UML. Or, even worse, “UML from which to generate some partial code.” In the new modeling discipline, models are much more than software models for forward engineering. Models can be partial, used just for sketching or as blueprints,⁶ and focus on rather different functions of the modeled system [16, 23]. Similarly, if you ask systems engineers, they will think of SysML models to represent the structure of their systems and Simulink or Modelica models to describe the equations of their behavior; these models provide partial views of the system, which must be ‘somehow’ merged together and combined with other models, e.g., battery power consumption models. A civil architect can think in terms of BIM (Building Information Models), combined with strength models of the construction materials. In biology, different models can recreate aspects of the functioning of human tissues or diseases, or represent strands of DNA. In short, every community tends to have a very narrow view of what modeling is. We all need to make an explicit effort to evolve toward a more inclusive perspective.

Indeed, each engineering or scientific domain requires different types of models and their combinations. So far, we have a solid understanding of those combinations more typical of software projects. We will need to develop appropriate bridges between these models, as well as new modeling techniques for other relevant combinations, often involving going all the way down from exploratory models to simulation ones. Multi-paradigm modeling [4, 29] should also play a key role in this context.

Even if we have the most inclusive perspective of modeling, we will soon realize that other communities do not call what they do modeling, or assign a different meaning to the word model. Or maybe they are just not aware that what they do could be regarded as part of a more global modeling initiative.

Before setting on a precise characterization of the new modeling discipline, we will need to conduct a systematic search of the many uses of modeling in different knowledge fields and invite people from each field to join the initiative. The former is more difficult than the latter. Once we identify the right people, they will likely be happy to participate, as many of them are already convinced of the benefits a proper modeling strategy could bring to their field—they just lack the expertise of doing it alone and the time to learn on their own how their “modeling” complements other “modeling” approaches.

As shown in Sect. 3, disciplines should be linked to teaching initiatives. We can probably take MBEBOK [10] as starting point, with slight modifications to broaden the scope.

Then, on top of this core content, we will need to see what specializations are needed for those domains with specific particularities. Probably, also depending on the profile of the student, since now not all students will come with a computer science background, so modeling for non-technical people will be an important point here. The systematic review above should shed some light on the number and shape of such specializations. In any case, variations of data and process modeling initiatives will probably show up in all domains, as they all need to store and process data. In particular, data interchange formats are the only typical fully specified domain description models we see in scientific fields.

Another important aspect is to have a clear distinction between “modeling users” and “modeling developers.” The first group needs to understand the modeling concepts, when and where modeling can help, how to model using a given DSL, or the tools to use, for example. The second group is the one that will create the DSLs, transformations and all the tooling infrastructure that the first group needs and will be using in their daily practice. In current modeling courses, both profiles are mixed, which is a mistake [12]. Many modeling users have zero needs (and interest) in being also modeling developers and will only get confused if we try to explain these advanced concepts to them.

A key role of the modeling developers profile will be the definition of DSLs for all the new domains we will be targeting. Definitely, there is no general modeling language (like UML) for the whole scientific field. While we can envision some DSL hierarchy, there is not much in common between a DSL for water treatment plans [27] and one for internal cell functions [14].

Defining new DSLs is a must as most domains use informal models (beyond low-level mathematical models for simulation) right now, not backed by any formal structure definition, i.e., a metamodel or grammar. The DSL is implicit (and ambiguous). Thus, the first step to evolve toward a proper modeling approach is making the DSLs explicit to clarify the important knowledge of the domain that should be represented and exchanged.

At the same time, we need to keep in mind that DSLs will now need to involve, more than ever, the modeling users of the DSL. Firstly, because we will be further than ever from the domain of the DSL. Until now, we could often rely on some partial knowledge of the domain when creating the DSL as many DSLs were semantically closer to our own software or systems background. This may not be the case here. Secondly, because we should not be the only ones creating the DSLs. With modeling becoming an independent discipline, people with different backgrounds may decide to take the role of modeling developers. And this may be in fact needed for scalability purposes as there may not be enough modeling experts to cover all the modeling developer needs. Issues such as the types of language workbenches that will be needed for this type of users, how to gather language requirements from this variety of domains, or the notations that are most effective for them remains to be seen.

To successfully integrate new domains in our new modeling discipline, it must be easy to onboard new users. Usability is already an issue with technical people [1, 31], we will need to make an extra effort for users with different backgrounds.

Improving existing modeling tools may not be enough. Instead, we should explore how to bring modeling to the tools they already use so that they are not forced to learn new tools. Or at least not new tools in a completely new environment or ecosystem.⁷

Even better if models do not need to be created from scratch. A partial model could be automatically derived from the data the user has already available or any low-level mathematical definitions it has already formulated. Or we could extend our perennial goal of model repositories [18, 24] to cover also non-software models. If none of this is possible, modeling assistants could also be very helpful [22].

Following up on the previous point, a modeling discipline needs to cover also the economic aspects of modeling. Economic models to calculate the ROI (return on investment) of modeling and other relevant economic metrics, depending on a number of domain and application parameters, should also be a core element of the discipline.

This is already an important point when discussing the adoption of modeling in the software industry, where the ROI should be easier to calculate as it is a more quantifiable domain. This will be even more problematic to compute in less engineering and more scientific domains.

While modeling experts may appreciate the beauty or elegance of a modeling solution, any other user will be only driven by the perceived benefits of the modeling tool implementing such solution. Modeling will need to embrace this pragmatic perspective.

The foundation of a modeling discipline will need to involve both researchers and practitioners. Like it or not, researchers’ participation will be linked to the possibility of publishing their contributions to the discipline in well-respected conferences and journals.

We know publishing interdisciplinary papers is difficult as they do not present a core contribution to any single specific area but to their interrelationship and many venues do not appreciate this type of research contribution. As a community, we must show there exists a viable career path for researchers in the modeling discipline.