 So now that we went very quickly through UML, mainly as a reminder, as I said, we go into the topic of what is a model, actually, what is the purpose of a model and what's the difference to a diagram. So a model, there's a definition in the in the slides that I'm providing, but there are three things that are really important in the model. First of all, it's a representation or it has a representation of the real world. So we are describing something in reality. For example, you could have a model, a paper or a wooden model of an airplane that just looks like an airplane, like a certain type of airplane that exists in the real world. Then there is a correspondence. So it somehow resembles something of this object that we are modeling. For example, the model of an airplane might look just like the real thing. It might look exactly like it be painted in the same way, or it might have the same size. So that's a different kind of correspondence. Maybe the color is not the same, but the size. It's a one to one model, for example. So these are different kind of correspondence you can have, or it could be built off the same material as the airplane, but have a very different scale. So a lot of different options you have, but something is corresponding to the actual real world thing. And then finally, and that's the key of all of this, there should be a purpose in it. So if you have a one to one thousand model of an airplane that looks like the real thing, the purpose is maybe just so it's an aesthetically pleasing object that you can hang in your living room because you like airplanes. So that could be the purpose. If you build a smaller version of the airplane out of the same materials, it might help you to reason about. I'm not an expert on airplanes, but it might enable you to do certain kinds of analysis on that. If you build, for example, a model of the wing of an airplane, maybe you can do some testing on the stability on it. So there should be some kind of purpose behind doing the modeling. And when we go into software engineering and doing models in software engineering, especially in UML, I very often see that this purpose is unclear or missing, especially in education. So you often see assignments that go do a class diagram of a library, but no one tells you what exactly the purpose is. Like what should you be doing? And this is really important because if you go back to the correspondence, if you build an airplane model, you could build a small wooden model. You can build a large one out of metal that has the same colors. They are all good descriptions of the real airplane, but depending on the purpose, the model might be completely wrong or completely right. So if you want to test the stability of the model of an airplane, then it doesn't make sense to build a small one out of paper because you somehow need to have the right materials. You need to maybe have a certain similarity in size. So the purpose really, really should push you to build a certain kind of model, certain things should be in place and somehow tell you what to exclude, what to abstract and what needs to be there. So if the purpose of your software model is to understand the structure of a system, it doesn't really make sense to do a state machine diagram, for example, because that doesn't really describe the structure. We'll go more into this, but keep this in mind. Whatever you're doing, it has to have a purpose. You shouldn't just do a model because someone tells you to, you need to ask why, what is necessary. And there are, in software engineering, a whole lot of things we could be doing with a model. Very common is the communication aspect. So maybe you are just drawing something so that you can discuss it in the team meeting. So here's a suggestion how we can break down the system into components. What do you think? Communication. If you do a communication model, maybe a lot of details you can skip. You don't need to worry much about the notation as long as everyone in the team understands it. You can skip a lot of the details because it's just about the overall structure, maybe. So this might enable you to do a much, much simpler model than if you have another purpose. You could do planning. Maybe you need to describe to a supplier to another company what your interface looks like. So then you need to have an interface specification, maybe a class diagram, maybe a component diagram that really describes these are the methods we're having. That's the dependencies that our components are having. This is what you need to implement. And if that's, for example, contracting, then maybe this needs to be much, much more detailed than if you just discuss it in a meeting. So different kinds of detail level and also maybe different kinds of needs, how much you can change them. If there's a contract, then maybe that's it. You have signed it, you have agreed on something, you have to implement this. If it's an early discussion about your system, then you can change it the next day. Then, of course, we have documentation. So drawing a component diagram so that in the next year you still know how your system is decomposed and maybe if there's a new person coming to your company, you can quickly describe this is how our system landscape looks like. These are the components and this is where you will work. So classic documentation tasks. Then you might have certifications. So maybe you are in a safety critical area and you need to adhere to a certain safety standard and that one requires you to have a model of, for example, the protocol, the communication between different things because that needs to be safe and secure. So you need to show a certain evidence and it's very common that these things, they might not require it, but a lot of this standard suggests that you can use, for example, sequence diagrams. You can use that. So in that case, you might have certain needs to draw certain diagrams. You can do analysis. One typical example is you have a state machine that describes how a component behaves. How does it go from one state to the next? And there are algorithms that can, for example, detect, are there any potential deadlocks? Is it possible to end up in a state that you cannot leave anymore? And that would be a problem. So those are things you can, for example, do on state machine diagrams. There are other ways. And here we can again reason that, of course, something that does analysis automatically needs to be very formal. It needs to have all the details, much, much more than probably documentation or communication diagrams. So a very, very different level of detail, a very, very different level of precision. And a model that you would do for analysis could be a really, really bad model for communication because it's way too complicated, depending on who you talk to, of course. A model for communication is probably not going to work for analysis because it needs much more detail. And then finally, we have generation of things. So we can take a model and we can generate code from it. We can take a model and generate documentation from it, pictures, whatever. Again, depending on what you want to do with a model, you might very much need different levels of abstraction. It's definitely not enough to just draw a picture, like on a whiteboard or a JPEG file. You need to have something that can be automatically processed. So there are the standard UML tools come in, like papyrus, like magic draw, that exist. And the main reason why I've been so detailed here is really to get across that this idea of just doing a model is really, really wrong without asking yourself what it's for. Because there's, for instance, a complaint we hear very often is about tooling in UML, that the tools are bad. That's because a lot of people draw models just for sketching for communication. And the UML models, they are much, much more on this level of detail. They require you to be very precise, what kind of arrows you use, what kind of things, what kind of information is in the model. So again, it's not only about the purpose of the model, it's also about choosing the tool that is fit for the purpose. If you just want to do communication, well, just use a whiteboard or a drawing tool. You don't need a UML tool. But the other way around also is true. If you want to do analysis, you cannot start drawing a picture in PowerPoint. So these are the purposes. There is one more thing that is orthogonal to this. We sometimes talk about descriptive, I'll just switch the panel over here. We sometimes talk about descriptive and prescriptive models. So a descriptive model describes something. It documents something that is already there. For example, the documentation of this is how our system looks like right now. You can use it for the future. This is how our system looks like right now. You can generate something from it. There's also prescriptive, which prescribes something. It tells you how it will be. If you, for instance, do planning, if you do analysis, what you are having in the model is the description of how the system will be. You tell, for example, your supplier, this is what you have to implement. So the prescriptive is sort of coming before you have the final product. It says this is what we will do. This is what you should do. The descriptive is looking back saying this is what the system currently does. There's two different purposes. And again, similar to the purpose being often forgotten, I see that this is very often mixed in education. That you get an assignment that tells you, please do some planning. Please describe how your system will look like that you are going to implement in two weeks. But then very often the grading is done on a descriptive level. In the end, you go back and see, does your model, does your diagram actually fit the system you have implemented? And that's a descriptive way of looking at it. So keep this in mind. There is not one model that fits everything. Whatever you need to do, we need to look at the purpose. You need to look at do we need to describe or prescribe something and then decide what is it that is necessary to get this correspondence to the real world. Now, I have been mixing it a lot. People are mixing it a lot. In general, there's this question about or this discussion about a diagram versus a model. What is a diagram? What is a model? First of all, a diagram is something graphical. A model doesn't have to be graphical. If you go into very many other areas of science, people mean, for example, mathematical equations when they talk about a model. So that's some statistical equation. For example, it doesn't need to be something graphical. So a diagram is a picture of something and in UML and in software engineering generally what we often mean is that a diagram is a view on the model. So you could, for example, your model, I'll just do it as a tree here. You could, for example, have two classes. They are somehow related to each other. You could have an interface somewhere. You could have a component and that component includes these two classes. And then you could draw a lot of different diagrams that work on this model. So, for example, you could draw a class diagram that shows how class A and B relate to each other. You could draw a component diagram that has the component and the interface. It doesn't show class A and B because that's not part of the component diagram. So it just shows part of the system. You could have a sequence diagram that shows how A and B communicate or A and B and the interface communicate. You could have a state machine diagram that describes how the class works internally. So the diagram is a view. It shows part of your model. You can also have multiple diagrams of the same type. So you could have a class diagram that just shows class A. You could have a class diagram that shows the rest. It depends on what you want to show with the diagram. So a diagram is a view of a part of your system, of a part of your model. The model is what's in there, what's in the real world with a certain correspondence. So there is a difference there, but you will find that a lot of people mix these things. Nevertheless, this is sometimes important to understand if you work with certain UML tools because they might treat this differently. If you want to make really complex descriptions of your system, you often need to have a model, but you need to have a lot of different diagrams. In software architecture, again, that's something we'll revisit later, but in software architecture it's very common to have different diagrams that show, for example, the components, but they also show the deployment, so which components are on which machines, on which computers, which is a very different way of displaying the information that is in the model. Okay, so that's this part. That's a really important thing to consider whenever you go into modeling.