 I want to finish up this module with a discussion on the issues of modeling. Modeling has in software engineering and also beyond. It has a bit of a bad reputation that in my opinion is related to a couple of different things, but it's important to be clear with them because there is benefit in doing it but there is not much benefit in just blindly applying it to anything. There are two things. The first one is that software modeling is very often equated with UML. When you say modeling people think UML and they don't like UML because UML is very complicated. There are two things here. First of all you need to understand why you can do a lot of things that are not UML and even if you use UML you can do it in a very sketchy, in a very abstract way. You don't always have to use the right arrows, you don't always have to use the right notation as long as that fits the purpose and as long as it fits the people as well. If you for example want to do a model, a diagram that you describe to other people, the arrows can be useful because everyone understands them in the same way but if you know that your team understands what you're drawing then maybe you can just ignore them. Similarly if you want to just have a discussion then maybe it's not important to go down in all the level of detail. The reason UML is so complicated is that on the one hand it's supposed to be generic, it's supposed to fit every given context and it's supposed to be usable for all sorts of things including analysis and code generation and for that you need details and you need very different semantics, different meanings of elements. So that's for example where we have all these arrow types because if you want to generate something you need to be precise. But modeling is not just UML, you can do a lot of different things, don't get too upset with this. The other topic to discuss is the tooling which again is related to UML. We have a lot of really bad UML tools and that's to some extent because UML is so complicated again. There are some tools like Eclipse Papyrus that really try to have the entire UML standard in their tool and that's just really really overwhelming if you're a beginner in this. So you get these 30, 40 different types of entities and relations and you don't know what to use and how to use it. So that's part of the complexity of UML but again think about your context, maybe you don't need all of this. But also keep in mind that if you do want to do very precise things like code generation, a lot of the simple nice to use tools are not precise enough. So that's the dilemma we are in. And finally a lot of these tools are old and outdated and haven't been maintained and that does not help obviously. So this is something to consider and then of course the agile movement is sometimes in conflict with modeling because modeling traditionally has been a lot about documentation, about doing a lot of planning, about breaking things down top to bottom and this goes very much against the idea of agile, of planning just in time about having the teams decide on their own. So this is often a clash but it doesn't, again it doesn't need to be, you can very well draw diagrams for communication purposes for example and then throw them away, you don't need to document that. So again look at the purpose, don't get too upset about just having all the details of UML for example. So these are the things and then finally that's a bit my opinion but I do believe it has a bit to do with education as well because we very often discuss all the different UML diagram types. This is a class diagram, this is a sequence diagram, this is how it looks like. These are the 10 different arrows you have but we don't so much discuss what I just did previously and hopefully that helped you. What is the purpose, why do you draw these diagrams and really think about the different levels of precision, the different levels of abstraction that you can have. You don't always need to go all in on all the precision of UML. So this is partly why modeling is maybe not always that popular. There are certain movements there, we'll cover more of that later in the course but for example one thing that I believe is quite important here is the movement of the so-called domain specific languages. So as I said UML is a general purpose modeling language, it should cover everything but that's really complicated so there's more and more movement in the research community to build specific languages. They can be graphical like UML but they can also be textual like programming code but they are made for a very specific purpose like for describing an architecture, the so-called architecture description languages and then usually these languages are much more usable because they're really tailored to a context and they can still be precise so they might be made in a certain way that you can for example generate code or documentation from them. So that's something we'll cover later but there are definitely interesting trends in this area and it's not just UML, keep that in mind please. Thanks for watching this module and that's all I have to say about modeling for now.