WEBVTT 00:10.580 --> 00:11.640 OK, very good. 00:12.200 --> 00:18.570 So that was the first year lecture will be talked about classes, instances and attributes and classes 00:18.570 --> 00:19.280 and stereotypes. 00:19.760 --> 00:24.560 Now I'm going to go into associations and links between classes and between objects. 00:26.090 --> 00:28.360 So we start off with associations. 00:28.370 --> 00:35.390 And yet again, I think you will see that there are a lot of kind of connections going back to the section 00:35.390 --> 00:37.320 about the philosophical foundations here. 00:37.880 --> 00:44.780 So we said that the people here are they have the concept of people that are making an agreement and 00:44.780 --> 00:49.830 relational properties becomes relationships between classes in your mouth. 00:51.680 --> 00:59.000 So here we could, for example, have two classes represent the salesperson's, salesperson's and customers. 00:59.420 --> 01:05.000 And if we think that there are some type of relationship between those two classes, that is going to 01:05.000 --> 01:07.820 be represented as an association. 01:07.820 --> 01:12.780 ECOMIL and Associations is the most common relationship that is used in class modelling. 01:12.780 --> 01:14.390 And we're going to use it all the time. 01:14.720 --> 01:18.750 And it's shown as a solid line between two classes. 01:18.980 --> 01:23.720 So if you see a solid line between two classes, then you see an association. 01:27.430 --> 01:31.330 Good, so typical relations star model with associates. 01:31.770 --> 01:38.320 And as I said, most relations are associations are, for example, you have an agreement that refers 01:38.320 --> 01:43.510 to a product, you have a salesperson that is using the product and trying to sell it. 01:43.810 --> 01:50.140 And you might have a process or sorry, product owner and a three solid lines. 01:50.140 --> 01:53.950 Here are all associations between those different classes. 01:56.540 --> 02:02.570 So association ends, that's the end bits of the association, as they are called, the association 02:02.570 --> 02:02.920 ends. 02:02.930 --> 02:07.580 So we have the solid line and then each association have to association ends. 02:08.150 --> 02:10.670 Each end could have multiplicity. 02:11.090 --> 02:16.610 So in this case, between the party and the agreement, I can state a multiplicity on the parties side 02:16.610 --> 02:19.580 here and the multiplicity on the agreement side here. 02:20.390 --> 02:22.270 And that's the two association. 02:22.280 --> 02:23.900 And so this association. 02:26.000 --> 02:34.920 So the multiplicity regulates which type of object constellations that are possible using this association. 02:35.330 --> 02:43.190 So in this case, in this example, it says that an agreement must have at least one party, but a party 02:43.340 --> 02:45.770 does not have to be involved in an agreement. 02:46.220 --> 02:53.930 So the one on the association and to the left here is indicating that it needs to be at least one object 02:54.410 --> 02:59.570 of an instance of the class party connected to every agreement. 03:00.050 --> 03:07.640 But this zero on the other one state that it doesn't have to actually have a party that doesn't have 03:07.640 --> 03:08.480 to have an agreement. 03:09.830 --> 03:14.000 The Asterix is showing that it could be multiple. 03:14.180 --> 03:18.440 So you're saying one or many or zero or many. 03:20.870 --> 03:28.130 So classes could have multiple association between each others and the associations could have rule 03:28.130 --> 03:28.660 names. 03:28.670 --> 03:30.920 So take this example with party in agreement. 03:30.920 --> 03:37.250 Again, we can actually have maybe three associations between the three between the two classes, and 03:37.250 --> 03:41.330 they might have multiplicity, as we just saw, but they can also have role names. 03:41.660 --> 03:47.990 So here we can actually have one association saying that an agreement had one party that is the client 03:48.440 --> 03:54.290 have another party, which is the supplier, and could have one or multiple parties. 03:54.560 --> 03:56.810 That is in the role of being manufacturers. 03:58.040 --> 04:07.040 OK, so that without its UML terminology, that is association name, have an association and have a 04:07.040 --> 04:10.850 role name, which in this case is clients apply to manufacturers 04:13.490 --> 04:18.860 and it specifies the role the class plays in the context of that specific association 04:21.320 --> 04:27.740 association and could also have something that is called navigability and navigability is shown as an 04:27.740 --> 04:28.280 arrow. 04:28.280 --> 04:30.660 But it's an open arrow because we come to that. 04:30.680 --> 04:33.700 So there is a closed arrow, but that is not actually an association. 04:33.710 --> 04:35.180 And then it's a generalization. 04:35.180 --> 04:40.640 But if it is an open arrow, then it shows the navigability of the association. 04:42.680 --> 04:48.610 So navigability shows and specifies if a class knows about this relationship. 04:48.980 --> 04:55.790 So we can say that an agreement knows about the product, so to speak, but the product does not know 04:55.790 --> 04:59.270 about its agreement or agreements that may refer to it. 04:59.270 --> 05:06.110 Maybe so that's a way of saying Canale, I know more than you do or I need you in some way. 05:06.110 --> 05:10.010 I'm a client or a supplier in terms of concept to concept wise. 05:11.120 --> 05:14.720 So navigability is actually quite important. 05:14.720 --> 05:19.520 But usually you don't start by having and stating each association is navigability. 05:19.520 --> 05:25.130 But once you have your concept model, your first sketcher we've kind of done, then you might go into 05:25.130 --> 05:28.250 and try to specify each association a bit more. 05:28.430 --> 05:32.230 But when you set it up, you probably just have to draw the solid lines. 05:33.980 --> 05:39.530 So if and if you don't have any arrows, if it's just a solid line, that implies that both hands are 05:39.530 --> 05:40.220 navigable. 05:40.220 --> 05:44.180 So that's a shorthand for describing the arrow in both directions. 05:48.020 --> 05:53.090 It could be a little bit confusing about the direction of the arrow here, because there's actually 05:53.090 --> 05:56.860 two quite different meanings of a direction of an area, UML. 05:57.290 --> 06:02.720 But when we're talking statically, which we do here because it's a static relation, we only saying 06:02.720 --> 06:06.680 that those two talking concepts have some type of an association. 06:06.680 --> 06:08.510 There's no dynamics going on here. 06:09.440 --> 06:14.320 Then we say that the agreement concept depends on the existence of the product concept. 06:14.590 --> 06:15.620 Not wise for us. 06:16.130 --> 06:16.550 Right. 06:17.570 --> 06:25.340 So the the the direction of the arrow is implying a dependency direction. 06:26.060 --> 06:31.880 If we're talking about then in UML as well, we can do an activity diagram, for example, and then 06:31.880 --> 06:39.170 we will have an activity like define product, which is done before we write an agreement. 06:39.650 --> 06:45.200 Then the dynamic meaning of an arrow is actually chronological meaning. 06:45.680 --> 06:51.390 But so we we first define a product and then we write an agreement. 06:51.780 --> 06:55.010 OK, but you maybe see the here as well, so. 06:55.270 --> 07:00.340 The agreement depends on the product and not vice versa, but we defined a product before we define 07:00.340 --> 07:02.740 the agreement and that's that's logically right. 07:03.070 --> 07:09.310 But it could be a little bit confusing if you're if you're going between diagrams are showing some dynamic 07:09.310 --> 07:12.960 flow and diagrams start showing static things UML. 07:13.450 --> 07:14.920 But we encountered models. 07:14.930 --> 07:16.540 We only talking about the static thing. 07:16.560 --> 07:18.900 So it is a dependency relationship. 07:18.910 --> 07:21.220 We are modeling, not a behavior one. 07:22.570 --> 07:27.100 So if we put this together for associations, we'll have, for example, like this. 07:27.160 --> 07:34.930 So we have an agreement with three associations to the concept party and an agreement is regulating 07:34.930 --> 07:39.430 the use of one or many products and product. 07:39.870 --> 07:42.980 A party is the owner of a product. 07:44.350 --> 07:49.030 So here we have used actually a number of associations we've used navigability. 07:49.030 --> 07:54.640 We used your name and you also see this a little bit, our road that is filled on the association. 07:54.640 --> 08:00.890 That is just a notation you can use in your email to simplify the how you reading the model. 08:01.240 --> 08:04.330 So what is regulating the use of the arrow? 08:04.570 --> 08:06.160 That is the reading direction. 08:06.580 --> 08:13.420 That's and that is maybe easier to say that a party owns a product so you don't miss mistakenly say 08:13.420 --> 08:14.890 that a product is a party. 08:15.070 --> 08:15.450 Right. 08:15.940 --> 08:17.530 So it's a reading direction. 08:20.790 --> 08:21.220 Very good. 08:21.600 --> 08:27.410 So that was associations, so let's go into what links are then maybe you've already figured it out. 08:28.140 --> 08:34.740 So links actually specify specific relations between objects. 08:34.750 --> 08:42.030 So if associations was between classes and hands, concepts, links are real world relations between 08:42.030 --> 08:42.560 objects. 08:43.590 --> 08:49.050 So we have this situation, the Romeo who loves Juliet and Juliet, who loves Romeo. 08:49.410 --> 08:54.690 And that would actually we talked about that in the philosophical part and the philosophical section 08:54.960 --> 08:58.970 that is denoted very similar directly in your mouth like this. 08:58.980 --> 09:00.330 So you have an object. 09:00.630 --> 09:03.000 Romeo are the class person. 09:03.210 --> 09:05.880 You have an object, Juliet of the class person. 09:06.180 --> 09:13.410 They have two links between each other, which is loves, and they are each other's agents in those 09:13.410 --> 09:14.060 two links. 09:14.640 --> 09:20.340 So the links are also shown as a solid line between two objects, but with the same thing. 09:20.340 --> 09:25.320 When we saw about instances like objects or classes, the name was underlined. 09:25.620 --> 09:30.810 And that is actually the same thing here when it comes to links so loves. 09:30.960 --> 09:37.790 If we are stating the name of the association that is instantiated will be in an underlying name, UML. 09:40.370 --> 09:46.340 So and that is I already said that now those links are actually instances of associations. 09:47.270 --> 09:48.590 So take this example. 09:48.590 --> 09:55.850 We have a person that can refer to one or many other persons in association on a class level. 09:57.260 --> 09:59.470 And the association here is called Loves. 10:00.410 --> 10:02.450 That is actually the class diagram. 10:03.140 --> 10:09.010 And below here is an object diagram specifying a specific love relationship. 10:09.230 --> 10:09.590 Right. 10:09.980 --> 10:13.240 So here we have Romeo loves Juliet and Juliet loves Romeo. 10:13.580 --> 10:19.550 They are two instances, a person, as we said, and they are actually instantiating this association. 10:20.120 --> 10:26.570 So the objects are instantiating the class and the links are instantiating the association. 10:28.640 --> 10:29.750 Quite logical, isn't it? 10:32.570 --> 10:36.710 So an association declares that there can be links between the objects. 10:36.740 --> 10:38.170 It's not saying that there are links. 10:38.180 --> 10:40.190 It says that it can be links between the objects. 10:41.810 --> 10:48.010 So you usually use object diagrams to clarify real world situations and scenarios. 10:48.320 --> 10:51.930 So it's good to use when the classifications becomes more complex. 10:52.520 --> 10:56.840 So this is a very simple one, but I will show you later on the next section when we are talking about 10:56.840 --> 11:01.160 how you actually do this in practical workshops, much more complex scenarios. 11:02.540 --> 11:05.080 And here's a real wars scenario for this. 11:05.090 --> 11:06.890 So we have a child with parents. 11:07.610 --> 11:11.840 And the real world scenario is that a child called Charleson is charcoaled. 11:11.840 --> 11:14.420 Sarah both have the same parents, Claire and John. 11:15.230 --> 11:23.450 OK, so that object is objects and links and above we have classes and associations and they are all 11:23.450 --> 11:24.600 the instances of each other. 11:25.040 --> 11:29.030 So I've said it now a couple of times that you can actually instantiate an association. 11:29.040 --> 11:29.790 It becomes a link. 11:29.960 --> 11:35.960 That means that in Jhilmil terminology, we think about this on one metal level up and saying we are 11:35.960 --> 11:43.670 saying that a class is a classifier, an association is also a classifier because they could be instantiated. 11:44.780 --> 11:49.430 And hence, what if I need to describe attributes for the association? 11:49.640 --> 11:50.730 You can actually do that. 11:51.170 --> 11:56.630 So an association can actually have attributes in what is called an association class. 11:57.500 --> 12:04.850 So you can say that a person have an association called employment in a company, but you actually might 12:04.850 --> 12:10.700 want to talk a little bit more about this employment so you can actually state that the employment is 12:10.700 --> 12:16.530 in association class and have a start when he started when he ended in the salary and so on. 12:16.970 --> 12:23.060 So association classes are shown as regular classes, but then they have a dotted line that connects 12:23.060 --> 12:25.580 them to the association that they describe. 12:29.510 --> 12:35.720 However, you could describe it like this, but if you think that that looks a little bit complex, 12:35.720 --> 12:37.540 you can instead use this. 12:37.820 --> 12:42.440 So that is pretty much saying the same thing, that a person has an employment with a company. 12:43.850 --> 12:48.470 So you can use both annotations depending on what do you think is the easiest one. 12:51.460 --> 12:56.920 Then there is a type of associations that are a little bit strong, more stronger, and they are called 12:56.920 --> 13:00.850 Composition's, so you can actually model compositions of objects. 13:01.570 --> 13:04.960 And we talked about that also in the philosophical part. 13:05.260 --> 13:11.400 So when we think that objects are composed of all the other other objects, we talked about Mariola 13:11.830 --> 13:12.430 theology. 13:12.910 --> 13:19.990 If you remember that, then that is modelled in humans as what is called aggregations. 13:20.710 --> 13:26.650 So typically here we have this table and we say that the table consists of four legs or one, two, 13:26.650 --> 13:33.760 four legs and a surface and the top, which is the top and the top and the table legs are also connected 13:33.760 --> 13:34.340 in some way. 13:36.040 --> 13:41.790 So typically a pretty instance is only attached to one whole instance at the time. 13:41.800 --> 13:42.250 Right. 13:42.820 --> 13:50.410 The composite aggregate are shown as a solid black diamond at the association and for the whole class. 13:50.920 --> 13:57.100 So in this case, the solid black diamonds are showing that the table is aggregating the top and the 13:57.100 --> 13:57.810 table legs. 13:59.440 --> 14:07.480 OK, but there is also an alternative, a little bit newer way of to model this, which are called compositions. 14:07.540 --> 14:12.210 So you can have composite classifiers in UML now and since 2.0. 14:12.790 --> 14:18.460 So instead of actually showing the table with a table and top of three different classes with an aggregation, 14:18.700 --> 14:25.660 you could show like this was saying that we have a class table and within that compartment you can actually 14:25.660 --> 14:32.590 show the composition, saying that within this table it got four legs, one to four legs, table legs 14:32.920 --> 14:41.080 and one surface, which is of the type top class, top and the table legs and the top are connected 14:41.260 --> 14:45.460 and they are both an aggregate aggregated within the concept table. 14:46.600 --> 14:52.390 So that's another way of representing it that some people might think is more intimate or some people 14:52.390 --> 14:52.960 might not. 14:53.320 --> 14:54.730 I just wanted to show you that. 14:56.770 --> 15:01.390 Okeydokey, so let's summarize classes sorry, associations and links then. 15:02.650 --> 15:09.910 So we have said that an association are shown as a solid line between two classes and name and reading 15:09.910 --> 15:11.180 direction could be shown. 15:11.230 --> 15:17.530 So an agreement has a party and I can have written directions in both directions if I like on association 15:17.530 --> 15:17.960 as well. 15:19.720 --> 15:25.560 So association ends could show multiplicity role names and navigability. 15:25.570 --> 15:27.700 So those are three things that you can show. 15:27.710 --> 15:31.000 An association and an association have at least two ends. 15:31.000 --> 15:31.360 Right. 15:32.080 --> 15:36.640 So here we have a real name client on the party side for the agreement. 15:36.640 --> 15:39.520 We have multiplicity on both the parties side. 15:39.520 --> 15:43.090 On the agreement side, we have multiplicity on the address side for the party. 15:43.090 --> 15:47.500 And also the navigability saying that the party knows his address, but not the other way around. 15:47.860 --> 15:52.720 The party concept is dependent on the concept and not the other way around. 15:55.030 --> 16:02.740 And we can also show a composite aggregation that we're saying that a party actually owns its addresses, 16:03.490 --> 16:05.240 if you like, if you think that. 16:05.290 --> 16:09.430 So this is, of course, related to which type of conceptualisation you have. 16:11.170 --> 16:17.830 Then we can show an object diagram with objects and links which are actually done instantiations of 16:17.830 --> 16:20.930 both the classes and the associations. 16:21.400 --> 16:28.060 So here we will have one party which we call Acme Inc, which is involved in two different agreement, 16:28.060 --> 16:31.220 a one and a two, and it's declined in both the agreement. 16:31.270 --> 16:33.550 So that's two links of the association. 16:33.550 --> 16:39.970 We have a bar and the Acme Inc. have two addresses as well, one visiting address and one billing address. 16:40.870 --> 16:47.020 So links between objects, which are instances of associations, are also shown with solid lines between 16:47.050 --> 16:47.740 the objects. 16:48.100 --> 16:53.500 And if you also show the association name, that will also be underlined. 16:57.330 --> 17:02.860 And there are many ways to tell a story, of course, and we've shown that it depends on which class 17:02.910 --> 17:08.040 of which conceptualisation to have about the real world, how you will actually model it, of course. 17:08.640 --> 17:12.050 But so there's many different ways of modeling the same domain. 17:12.900 --> 17:17.370 And that depends on what the experts think is important to consider important here. 17:17.910 --> 17:24.300 So I can model like they're saying that a parent might have child sooner than a child, might have up 17:24.300 --> 17:25.040 to two parents. 17:25.980 --> 17:32.760 But I can equally maybe say this, saying that a person has an association to other persons and in that 17:32.760 --> 17:38.700 association they are either parents or children or I can just model it saying that a child have an attribute 17:38.700 --> 17:43.230 of a father name and a mother name, depending on which type of domain in which type of system I'm doing 17:43.230 --> 17:51.150 now and watching what is important in our current analysis, the different kind of details in this could 17:51.150 --> 17:51.770 be used. 17:52.140 --> 17:55.620 So and that is most important because there are no true and false here. 17:55.620 --> 18:01.410 They are more like if it's usable or not in our current situation and you don't want to have too much 18:01.410 --> 18:03.630 details if you don't need them. 18:03.900 --> 18:08.760 But in the other way around, you don't need you don't want to have two less details to be able to express 18:08.760 --> 18:09.390 what you need. 18:12.480 --> 18:12.880 Very good. 18:13.620 --> 18:15.460 So that's the end of that lecture. 18:15.460 --> 18:17.570 And that was about associations and links. 18:17.940 --> 18:24.000 So now we're going to talk about the other specific relationship called generalizing generalizations.