 So, before we dive really into the topic of architecture, the first question or the first thing to look at is the UML component diagram as one way of representing the architecture on a high level, very abstract. And what the UML component diagram is, it's a high level, whatever that means, it's a high level view of components, as the name suggests, and the interfaces. And now of course, one of the first questions you might ask yourself is what actually is a component. We talk about that a lot. And in general, what we say a component is, it's of course some kind of unit of composition. It's some kind of piece that you can use to compose your system. That's an easy way to say it. But another important aspect is that you should be able to deploy a component independently. So it should be a piece of your system that can be deployed, that can be started without the other parts of the system. It might not be fully functional because it might need other things to work as intended, but you can at least deploy it, you can start it. And that's of course, if you have a very complex system, that's a very desirable property, that you have a lot of components and they depend on each other, they require their services, but at least they can be deployed independently. For example, I could deploy one component on one computer and another one somewhere else. So this is in general what a component is. Furthermore, talking about the dependencies, a component has explicit dependencies to other components. And what that means is simply that you say, well, I have a component here and it requires other things to work. For example, I have an online shop and that's one component. I have written this online shop in whatever, in JavaScript and I deploy it on the web. It's independent so I can run it, no problem, but for it to work properly it requires another component, which is some kind of payment service. So you can shop, you can put things in your basket, but in order to actually be able to pay, this component requires explicitly another component that deals with the payment. And that one could be running somewhere else because it's also independent. So that's what a component is, what the overall idea is. And to represent this in UML, you basically use boxes for components. So you have a box, a rectangular thing and you write component in these angle brackets. So it's a stereotype component. This is a component. I can give this a name, for example, this might be my payment service. So this is the component that can handle payments. It has an interface to do so and we'll get there. And then I have another component. I'll just write comp here to keep it short. This is my web shop and this one is also independent. I can deploy it so I could put this on one machine, I can put this on another machine. And now these are the components, but we also need the interfaces here, the dependencies. And this is done, it's often done using the so-called lollipop notation and that's basically a line with this round circle at the end, so it looks a bit like a lollipop. And this means this service here is providing something. That's what this means. It provides some kind of functionality. And then we have the opposite, we have the notation that our service requires something. So this is how we typically represent an overall system, an overall architecture. You can say that in our case, we have two components. We have the web shop, we have the payment service. The web shop requires some kind of payment service and the component we have here is actually providing this functionality, it's offering it. This is often the preferred way of drawing this because it's very simple, so you can represent an entire system on an extremely basic diagram. But you can also go into detail, so you can basically unroll this and instead of this lollipop notation, you can draw an interface, which some of you might know from the class diagram in UML, so you can have a box with the stereotype interface. We call it, for example, I payment service. So this is our interface that provides some kind of payment service. And then as you do in UML with classes and interfaces, you can have methods. You can, for example, say there is a public method called make payment. And you could, of course, add all sorts of parameter and return values here. I skipped that. But essentially, instead of doing this very basic overview with a lollipop notation, you can also go into detail and really discuss how does the interface look like? What kind of methods do you have? What kind of parameters do they need? What do they return and so on? So that's the more detailed view. And of course, there is nothing that says that a component cannot have multiple provides or multiple requires. So the payment service could, for example, have another interface here that provides some other functionality. For example, for a bank to interact with it, or it could actually require something else. So that's also possible. Then if you want to have a fully functional system, you actually have to have some kind of component here that provides this functionality. So this is what we would typically have in a UML component diagram. Of course, as it is with UML, there are many more details to this. So you can definitely go into depth and look at all the details if you want. But in many cases, if you look at software architecture, this is sort of the level that you'll see. Components provides and requires interfaces and if needed, details on how the interface looks like. OK, that was a quick overview of the UML component diagram. Now we really go into the topic of how do we actually do software architecture, what are the important things to look at.