 So, first up we discuss the UML, the unified modeling language and what kind of diagram types it offers, what kind of things you can describe. And there are a number of things you might want to describe and we categorize them roughly into four areas. We might want to describe the context of our system, so how does it relate to the outside world, how does it relate to other systems and so on. Here we actually don't have any direct UML diagrams. So there's no diagram that says, that is particularly well suited for context, but very often we use, for example, class diagrams or component diagrams, so they do fit into that. Then we have the so-called interaction diagrams, so describing how several components, systems, subsystems, several units communicate with each other. And the prime example here is the UML sequence diagram and this, I hope you all remember, you have actors, you have what is called a lifeline and you can send messages between them, for example, asynchronous messages or you can have synchronous messages where you have these bars on the right side and they return. And the important thing is, that's why we talk about interaction diagrams, we have several components here, there might also be a user somewhere else, but the idea is you describe the interaction, you don't really describe what these things do individually. You have these kind of calls sometimes that the component calls itself with something, but the main focus is really on the interaction and what's going on between. And that's really important, for example, if you have two components, two systems developed by different companies and you want to in detail describe how they should communicate. The protocol between them, maybe you have to have A being sent before you send B. So these things are, for example, very, very common if you go into the network area in a lot of the standards and a lot of the RFCs request for comments that describe network standards like TCP, IP, you find drawings that look exactly like sequence diagrams because for them, this perspective is really important. They don't care what A or B are doing internally, but it is really important what is being sent in which order between them. So there we have the UML sequence diagrams, then we have structure. So we might want to describe how a system looks like, how it's decomposed. And again, the prime example here is the UML class diagram, which you're probably most familiar with. So we have these boxes that describe different classes. They might have attributes, for example, name. They might have operations, these things here, for example, A. And of course, you can add things like types, parameters, return values. You can have interfaces, you can have abstract classes. And we have associations between classes that describe how they relate to each other. And then there is something that I would like to mention here in detail because I've seen it being forgotten very often. And that is the multiplicities and role names between different classes. So you always read from the start of the arrow to the end. So if I, for example, say client1.star, this means A has one too many clients that are of type B. So I read in this direction. If I have an association that goes in both directions, you could, for example, just have supplier1. And this would mean A has one too many clients, B has one supplier. So you always read from the start to the end and the role name and association are read kind of to the further end. That's the way it works. I have often seen it being inverted. So take care that you get that right. Now, as I said, these things are very often used for context also. For example, they're used to describe what kind of domains are there, what kind of elements do we have in our context. So imagine you're describing, for example, a library system, the classical example. You could have a domain model, a class diagram that describes what is there in a library. You have books, you have loans, you have user accounts, you have maybe certain areas in the library. So these things you can describe in the class diagram. You're not really describing a system structure, but you're describing the context of the system. You describe logically what the domain contains. So that's very often what we have here, the so-called domain models. And these are sort of abstract things that are very often described using a class diagram. But they're not in the UML because the UML is an object-oriented language to describe systems. So it doesn't really fit to describe a domain with them. But the class diagrams are used for that regularly. The other thing we have here are UML component diagrams. And as I said, I will describe them in the next video in a bit more detail. But component diagrams look very similar to class diagrams as boxes and lines. But instead of single classes, they describe components which are units that can be executed in isolation. So a component is like a small application that you can run on a computer. Another component is executed somewhere else and they can communicate. Whereas classes are usually run in the same components that they belong together in the programming language, roughly speaking. So component diagrams are very important to describe the structure of a system on a high level. And then finally, we have behavior diagrams. And behavior diagrams are, well, they describe behavior. But in contrast to interaction, they don't describe what's going on between A and B. They describe what's going on in A or in B. So here the focus is not how do several units communicate, but how does one unit work? And the classic example is the UML state machine diagram. So we have states, there's also the activity diagram, which also describes behavior. But we have states, for example, state, idle, and active, and error. This would describe a system that is very, maybe a very basic model for a lot of devices, like embedded devices, that are either idle or they do something when they get activated. They might get deactivated again. They're still on, but they're somehow idle. And from every of these, there could be an error happening. So then they end up in the error state and they usually don't leave the error state, but then they're sort of done. So these really describe what's going on here. So for example, A, our instance A here could have this behavior internally, but then it communicates with something else in a different way. So these things are very useful to describe the state of something, the behavior of something, very common in a lot of embedded systems that you describe. How does one component work? So this is extremely common. There's extremely important. Think about, for example, robotics. Think about cars, different components in a car in an airplane. There, this view really fits well. This is more sort of network level communication between different things. And then the structure is really whenever you want to describe how something is decomposed into pieces, which is a very, very common use case in pretty much all engineering. We usually try to take the big system and break it down into pieces so that we can deal with those pieces independently. And it's much easier than trying to figure out the entire system. So that's the scope of what UML offers. And of course, there are much, much more diagrams. I always forget there's 12 or 14 different diagrams you can have. But honestly, sequence, class, state machine diagrams, component diagrams and probably activity diagrams, those are the 5, 4 to 5 that you should really know because they are being used a lot. And even if you don't see them in wherever you start working in industry, in certain areas it's almost impossible to work without them. People might not always draw them, but you should be aware that these things exist and they can be extremely useful to express what you want to do. So that's the overview. Next up, we'll discuss the component diagram just to give you a bit of an insight there. And then we go into the discussion about what is a model, why should we model and all of that.