 Okay, as a last part in this module, we'll discuss the concept of building our own modeling languages or what I've already mentioned domain-specific languages. So UML, for example, is complex and it's general purpose, so it's supposed to be usable for everything in the software world and that makes it extremely, extremely complex. And that's why, especially beginners are often confused by all the different elements you have, but at different arrows and don't even go to the level of what does all of this actually mean. So sometimes you want to have your own specific language and there are different ways to describe a language. If you have ever taken a compiler course or will, then you will get used to the concept of grammars or textual mathematical notations that explain what kind of concepts are you allowed to use, what kind of keywords are there and so on, but in the modeling world, very often what we use is a model to describe a language and this is known as a meter model. So it's a model that describes what kind of models you can create and this is a very complex concept, so I just thought of describing it using an example. So if we go back to our state machine we have states and transitions between them and they can have events, for example, add and then we have these kind of special ones we can do. We can end the state machine and if you would now like to describe the language of state machines, so what can you do in a state machine? We could draw another diagram, another model that describes them and what is common is to use the class diagram notation. So and I'll just sketch this because state diagrams, state machine diagrams are extremely complex as well. You can do a lot of things so I'll just show you in which direction this would go, but what we first of all have are states, so we can just have a class state and there are of course a number of different attributes we can set here. We have for example a state name. I skip the parameters for now. There might be other things, for example, in a real UML state machine diagram you have the actions inside the do, entry, exit actions. We'll skip them here. You have transitions and a transition in a state machine is always directed. It goes from an origin to a target, so a transition connects two states. One of them is the target state. The other one is the origin state. And each state can have a number of outgoing, no now I have to make this the right way around. This would be the incoming ones and a number of outgoing transitions. So basically the transitions that leave the state machine like this transition is an outgoing transition of state A and the ones that come in like B has the incoming transition here. So this kind of describes what kind of states we have and how they're related. Then of course a transition in our case just to keep it simple every transition can have an event. Again, we can make this more complicated. I think in practice they can have multiple events and they of course can have guards when you're allowed to take that one. They can have effects. So there are a lot of things there but to simplify it here we say each transition has let's say one zero or one event and each event could theoretically be used in a number of transitions. So that's what we have there. Then of course you can start making this more complex. For example in the UML state machine diagram we have a parent state. So we have hierarchies. My pen is starting to lose it. But we could for example support this by having a composition in UML so we could say a state can own a number of other states. So this is basically how you can sketch these things and what we have here is a formalization, is a description of the language of state machine. So this is a meta model of a state machine model. So that's something if you do language engineering or if you go into model-based engineering you want to do code generation or generate other things you will work a lot with these kind of models. These are usually basic class diagrams that describe the language and if they're small then they're simple to understand. So this is very good but this is also why I don't show you the UML meta models. They are also described in class diagrams but they're extremely complicated and usually there are several class diagrams to describe a single notation, a single UML diagram. So this is beyond the scope of this course, but you should have at least seen this concept of a meta model. There's one thing that is important to mention here that I'm not going into is we have constraints usually. So it's not enough to have this meta model but there are certain restrictions we have to have. For example, if you look at this we have an origin and a target. We need to make sure that we cannot do arbitrary things. For example this diagram, this class diagram would allow us to say that this transition here has as an origin class A but we could model this in a way that class A does not have this transition as an outgoing transition. So we could theoretically do that and that's something we need to restrict so we need to make sure that these things add up. So if a transition has an origin then that origin all still has to have this transition as an outgoing transition and so on. So usually we enhance these meta models by additional constraints to make it consistent that you can only do valid models basically. Okay so this concludes the model based engineering module. As I said this is a short run through the topic. I would encourage you to take a further course on this because it's very interesting often misunderstood topic about how you can use models in software engineering and as I said before the important message is not just UML. You can use a lot of different things and if you understand this in depth it's quite a powerful tool for software engineering.