 Okay, next up we have the UML component diagram and as discussed component diagrams are extremely useful because they are really good to describe the system in a very concise, very kind of easy abstract way without going to too much details. But first up we need to ask ourselves what is a component because we use this word a lot and it's good to know what it actually means. So it is obviously some kind of unit of composition. So we somehow break down our system into components and then compose it together. I've mentioned that before that for example in the reuse based process we would like to take existing components and put them together. So it's some kind of way of composing your system or part of it. What they have is they need to have specified dependencies. So you somehow need to have kind of usually called the contract a way of describing this is what the component needs. For example a component that draws something on your screen like a graphical user interface might depend on certain libraries for doing so and that needs to be defined so that whoever wants to take this unit of composition and put it into their system they can reason about what else do we need to run this. So that's really important the specified dependencies which is called the interface or the interfaces you can have multiple of those and finally what we can do is we can independently deploy these. Let's see independently deployable. So that means they each run sort of as an individual application and then communicate with other components over different protocols. But that means they can be running on different computers. They can be running in different platforms like on Windows or Mac. They can use different programming languages. So you could have one component that is written in Python you can have one that runs on the Java or JavaScript or something else and that makes this a very powerful tool a component because you can really build systems on based on a lot of different technologies and that's good if for example you have different companies that use different technology like one is programming in Python one is programming in Java or even within the same company you can basically leave it up to the teams to say this is your component use whatever technology fits you best. So that's why this is a really good way of breaking down your system and reducing the complexity. Now how do we describe this in UML? We have the component diagram and there we have components they look like classes it's a box and now my pen is giving up so we have components for example let's say we have the client it's one component they have this component stereotype so the double quotation marks the angled one component and then the name client and then let's say we have a server we don't go into details on what exactly they do so we have another component server just boxes and they should communicate so what is about the dependencies and here we use often what is called the lollipop notation what we have here is the filled thing that's why it's called lollipop the server is providing something is offering something so this is a way of saying the server has some kind of functionality that someone else can use and the client is requiring this functionality it depends on it so this is the dependency that we are specifying saying the client cannot run reasonably without the server the server does not have any dependency so it's fine the client needs some and then you write here that we are using this so again two angled brackets and use whereas this is the provides statement and then you can add a name here you can for example say this is i server func that's just the name of our interface so interface server functions or something that's just the name we assign that the interface is called we could have more of those so the client could depend on something else the server could depend on something for example maybe the server needs to have some kind of database connection then we could specify that as idb or something and we don't have to continue here but you could imagine that there is a database that provides this functionality and so on so this is a way each of these could be extremely complicated but it's a very easy way to say we have these two components and that's how they are connected what you see very often here i've been drawing the lollipop separated but what you very often see is that people connect them so they say well if if this is how our system looks like we just draw it like this so they are connected that's how our system is deployed and by writing use here we know that the client is the one that is using that is requiring it and the server is providing it so that's something you see very often there is another view that is the actual full notation and for completeness i want to mention that as well especially because it can be helpful to to be specific there you can describe in detail what your interface looks like and for that let's use this name iserver funct and what we have here is an interface that's something you might have already seen in the class diagram because there you can use these as well so it again looks like a class and it doesn't have any attributes because interfaces are abstract and they don't define any attributes but they define a method signature they define operations so you could for example say log in and i don't know get posts and then instead of this notation what we can do is like this so we have an arrow dashed arrow with an open arrowhead and we have a dashed arrow with an empty closed arrowhead and this means this one is using this interface this one is providing it we're implementing it so this is the long the explicit version of the small thing here and the advantage is of course we are seeing exactly what is in that interface what kind of methods do we need to implement on the server and what kind of methods is declined trying to call so this is somehow the more explicit version compared to this that's the original uml notation this is the short version that is typically used in a lot of systems because it's much more readable but if you need to know the details on the interface of course you somehow need to have this somewhere so that is the uml component diagram that's all i want to talk about because it is really not much more complicated there are some more things you can add there that is for example something that's called a port but we're not going there so this is usually enough to understand what a system is composed of and it's enough to describe your system on a very high level so i have for example seen these diagrams when i did evaluations for a government contracts when the suppliers needed to describe how their system looks like and how it relates to other systems what kind of dependencies it has then it's a very good way of describing your system without going into all the details but enough for me as an external person to understand what the system is roughly composed of so very common and we'll definitely see them again when we get to the software architecture part of this course