 So, in the second video, we'll start by discussing to what extent model-based engineering is actually used in industry, because a lot of you, especially also the ones that have worked already in industry, might not have seen any kind of modeling, model-based engineering, so it's quite a common question to say, is this actually used? Does anyone care about this? And the answer to that is really two-fold. One is it is used in specific areas that many of you might not be familiar with, and the other answer is that a lot of times I would say the use of models is a bit disguised as something that you wouldn't directly recognize as modeling, because a lot of you will have the impression, and a lot of people in general, they have the impression that modeling is drawing a UML diagram, and that's not necessarily true. But if we look at the main use cases, it's definitely relatively common when you talk about complex or large systems, because the complexity increases, and we would like to be able to decompose, have a separation of concerns, and modeling can help there. In particular, we often see modeling in the area of safety-critical systems, where sometimes, for example, you would like to rely on generation of code instead of having to write everything yourself, which might be more error-prone. In particular, that's related to these two topics. Modeling is very common in the systems engineering domain. So systems engineering is generally, to simplify it a bit, software and hardware. So if we're talking aeroplanes, if we're talking cars, if we're talking anything that is not just software, but you add hardware to it, and not necessarily only electronics, but it could also be mechatronic components or other things. So the combination of this makes it very complicated, and that's where models can help. Also, you rely often on the hardware, which, while you're developing, might not yet be existing, so there's much more need for having, for example, models that can model simulate the environment around your software. For example, simulate a certain type of hardware that doesn't exist yet. Or if you're developing the software for a car, it can simulate the physics of, for example, the road, even though you're not driving on the road. So in these areas, it's fairly common. So that means we're talking very often about the automotive domain, we're talking about the avionic domain, we're talking about railway, and so on, the classical systems engineering domains. But on the other end of the spectrum, we also see modeling in, for example, information systems. So these large systems that are used by companies to store and retrieve information. I've mentioned them several times in the course. The course book talks about the medical system. And in information system, you always have, or you typically have the case that several systems are rather similar. They are only different in terms of how exactly the company looks like, what kind of information do you need to store? And that usually depends on some kind of information model in the background. So it's not uncommon there to use model-based engineering because the system itself, you can very often generate based on the underlying information model and maybe some kind of rules. But you don't need to rewrite it for every single case. So here we also see the use of models. And then another, which is not a domain, but a use case that is rather successful is the one of model-based testing, so that you use models to test, to write test cases, to generate test cases automatically. And this is also used in many other domains that have nothing that are not safety critical or not information systems. For example, one company that you probably know is Spotify that uses model-based testing heavily to test their software. So regular consumer software, but the use of models for generating test cases can be quite useful. Because as you know, as you have seen in the testing lectures as well, testing can very quickly explode if your software or if your class or function, whatever your testing has a lot of different states, you very quickly get into the state space explosion. You have a lot of tests and being able to generate them and maybe generate depending on a certain strategy can help you to reduce this. And then finally, something that has to do with the first part of my answer. We have something that is called domain-specific languages or DSLs. And those are essentially languages that are specific, that are tailored to a certain use case. For example, you might have a textual language that looks a bit like programming, but it's made specifically for a mechanical engineer to express his or her mechanical components. Or it's made for a nurse or a doctor to write down case-specific things for a patient. So textual languages or graphical languages that are made for very often non-programming people. This is sometimes also known as language engineering. And this is why I mentioned in the beginning that very often models come in disguise. You don't know that it's a model because it's just some kind of, it looks like a programming language, you're writing text. But in the background there is actually modeling going on. And there is some kind of smart tool, which is a model transformation, that understands for example what the nurse and the doctor is writing and can automatically take action. For example, generate a report or so on. So this is another area that is becoming more and more important. So it's not only about writing UML diagrams, drawing nice pictures, but this can be very textual. It can have nothing to do with software whatsoever. It's a language for some kind of real life use case that is not programming. So this is all nice. What are the issues we are generally facing? One of them is, I would say, acceptance in particular by software engineers. So we as software engineers very often take pride in our programming and it's some kind of skills, some kind of craft that we're good at and we like it. And telling us to model instead challenges a lot of people. So there is a certain acceptance issue among software engineers and that can generally lead to organizational resistance. So changing the culture in a company is extremely challenging if people don't accept this. And not only if you have software engineers that don't want to let go of programming, but generally we are slow at changing. We're resisting change. So many people, if you would like to introduce model based engineering, would resist because they're afraid that they're losing their sort of specialty that they're going away from where they are. So it's often challenging to introduce this. And then I would say the third issue that comes up a lot is tooling, especially if we do graphical modeling. I think most of you or many of you have worked with UML modeling tools. They're often difficult. And this is not because people are too stupid to write tools. It's simply because graphical modeling is actually quite difficult. There are many dimensions to it. I mean, you know all the different boxes and all the different arrows and they all mean different things. And you might not have gotten to that level, but theoretically all of them have a lot of properties that you can set. And mapping this to a graphical tool, especially for a general language such as UML, is really difficult. So that's why there are a lot and a lot of tooling issues surrounding modeling. And that does not help. But important is the automotive industry, for example, clearly shows that this can be done. So it's not only about the tools. The tools sometimes are not optimal. But if you have a clear use case, if it's clear what you're using it for and it's accepted by the people, then tooling is in the end not the biggest issue. Okay. So that's sort of an overview of what is model-based engineering? Where is it used and what is it used for? And now we go into a couple of examples just to sketch what this really is.