WEBVTT 00:10.300 --> 00:11.380 OK, welcome back. 00:11.410 --> 00:14.260 So now we talked about the evaluation of package structures. 00:14.710 --> 00:18.190 Now I'm going to talk about how we actually derived the dependencies. 00:18.190 --> 00:20.590 I've already mentioned this in a number of times. 00:20.590 --> 00:24.110 I think it would be good to just have a short lecture about just that. 00:25.330 --> 00:25.960 So. 00:28.510 --> 00:34.030 Here we have two packages, and the packages only could only actually have one relationship, and that 00:34.030 --> 00:35.000 is a dependency. 00:35.800 --> 00:42.130 So a package could depend on another package and that is drawn in UML like this and that. 00:42.160 --> 00:48.490 We also mentioned that what we went through this interview, Mel S. So it's a dotted line with an arrow 00:48.850 --> 00:51.420 that shows the direction of the dependency. 00:51.430 --> 00:54.980 So here are the left package is dependent on the right package. 00:57.280 --> 01:02.360 So dependency direction is a product of the included classis relationships. 01:03.940 --> 01:13.000 So if we had four packages, the four packages included in this simple example, four classes, one 01:13.000 --> 01:17.170 class, have an association with the navigability going downwards. 01:17.980 --> 01:25.660 Another class that implies that we also have a package dependency in that direction between those two 01:25.660 --> 01:30.400 packages we have in another association going from left to right here. 01:31.210 --> 01:35.530 That also then, of course, implies the same type of dependency between the packages. 01:35.920 --> 01:39.470 But we can also have a generalization going in that direction. 01:39.490 --> 01:46.210 So you're always follows the arrow, so to speak, and that also then implies a dependency between the 01:46.210 --> 01:46.830 packages. 01:46.870 --> 01:54.100 So both associations and generalizations between classes implies the package dependencies or. 01:55.210 --> 01:58.270 The package dependency is actually the product of that. 02:00.070 --> 02:08.380 So an association without the navigability specified implies actually a double directed navigability. 02:08.860 --> 02:12.280 So we also mentioned that when we talked about associations in the U. 02:12.280 --> 02:13.150 Mel S.. 02:13.540 --> 02:20.530 So if you have an association without an arrow, that actually means implicitly that they are arrows 02:20.530 --> 02:22.180 in both associations. 02:22.690 --> 02:28.660 Hence, if you have an agreement and a product and just an association between and we know navigability, 02:28.900 --> 02:37.240 that actually implies double the direction dependencies that are actually in place to dependencies going 02:37.240 --> 02:39.730 in one each in different directions. 02:41.740 --> 02:44.980 So then we have a co-dependency between the two packages. 02:46.670 --> 02:53.840 So would you should try to strive it here is try to get the dependancy association navigability, follow 02:53.840 --> 02:57.000 the abstraction level of the concept and what I mean with that. 02:57.680 --> 03:02.880 So, for example, here the partisan products exist without any agreement, but not vice versa. 03:03.590 --> 03:10.220 So you can have a product and you can have a concept about a product and you can have a concept about 03:10.220 --> 03:13.250 a party without ever talking about agreement. 03:13.760 --> 03:20.300 But it will be very hard talking about the concept of an agreement if you don't already have a concept 03:20.300 --> 03:21.650 about product and parties. 03:22.790 --> 03:32.180 So in that sense, the product and parties are more generic concepts than agreement, and hence you 03:32.180 --> 03:34.820 should try to reflect that in the association. 03:34.820 --> 03:41.390 Navigability and therefore also the package dependancy if you would like to build in flexibility and 03:41.390 --> 03:43.250 modify ability to your models. 03:44.480 --> 03:51.860 So this is probably not a good idea to have a double directed navigability of the associations between 03:51.860 --> 03:57.680 the agreement party and product, because that also gives you double dependency direction on the packages. 03:58.220 --> 04:00.430 Instead, you should probably have this. 04:01.820 --> 04:08.150 So therefore agreement dependent parties and products and the dependency on association navigability 04:08.150 --> 04:12.720 should go from the agreement package to the parties and product packages, not vice versa. 04:13.800 --> 04:19.880 I hope that makes sense and this is something you usually do not maybe during the workshop, but when 04:19.880 --> 04:25.160 you are actually document and start reflecting on the concepts you have found, then you start kind 04:25.160 --> 04:28.250 of fiddling around with the navigability of the associations. 04:28.250 --> 04:33.740 And when you're creating packages, so you see that you actually get double directed dependencies that 04:33.740 --> 04:35.210 you didn't want to have. 04:37.430 --> 04:39.740 So we should try to strive for here. 04:39.740 --> 04:45.140 And this is something very important where you do software development as well as to avoid circular 04:45.140 --> 04:46.070 references. 04:46.580 --> 04:49.190 So a circle of reference could be just between two packages. 04:49.190 --> 04:50.330 So just show you here. 04:50.540 --> 04:56.510 But it could be a little bit more complex that it goes actually through a couple of packages and then 04:56.510 --> 04:58.520 you come back to the first package again. 04:59.150 --> 05:05.000 So of dependencies make packages inseparable and hence reduce the reusability and modify ability of 05:05.000 --> 05:05.520 the model. 05:05.570 --> 05:13.640 So what I mean here is that I cannot actually just pick out one package here from the model because 05:13.640 --> 05:18.890 that means that if I pick out that package and would like to have that in an animal, I need to I need 05:18.890 --> 05:23.630 to take along all the other packages because all packages depend on each other. 05:24.290 --> 05:30.650 So if I don't have that, that I can pick out the package and just the suppliers to that package, so 05:30.650 --> 05:31.220 to speak. 05:32.990 --> 05:38.270 So we should try to do very carefully here is to analyze the associations and the other relationships, 05:38.270 --> 05:44.420 like generalisations over package boundaries and the class as an abstraction level thoroughly. 05:45.110 --> 05:51.160 And then you should try to get the correct association navigability at this point. 05:53.240 --> 05:57.380 So try to get all dependencies to either go upwards or downwards. 05:57.530 --> 05:58.660 So what I mean with that. 06:00.800 --> 06:01.900 So if you have. 06:03.590 --> 06:10.850 The parking structure like this on the diagram and maybe also in your model than with the classes, 06:10.850 --> 06:16.340 because usually maybe when you start off the in, you just surround a couple of classes with packages 06:17.000 --> 06:28.010 and then you see here that so C is dependent on both A and B and B and D is dependent on B, A is dependent 06:28.010 --> 06:28.760 on B and so on. 06:29.000 --> 06:34.760 You see that you have Aerostar going both upwards and downwards in the same diagram, and that makes 06:34.760 --> 06:44.840 it a little bit hard to analyze for any maybe certain references or to see where the most generic concepts 06:44.840 --> 06:45.150 are. 06:45.310 --> 06:48.980 So I usually put my most generic concepts in the bottom of the diagram. 06:49.220 --> 06:52.180 You can put it in in the top of the diagram as well. 06:52.460 --> 06:56.750 I think it's easier because it rhymes more well with the what it's called layers. 06:57.890 --> 07:02.360 But so you should try to try doing something like this instead. 07:02.630 --> 07:09.740 So in this specific case here, it seems like the package E and the package B are the most generic ones 07:09.950 --> 07:13.160 because they have only actual dependencies going into them. 07:13.790 --> 07:21.260 And then you have package A who depend on package E and B, bad C is also dependent on A, and then 07:21.260 --> 07:28.220 you have C and D, whose only clients to other packages here, they are not the supplier to any of the 07:28.220 --> 07:28.780 packages. 07:29.750 --> 07:31.760 So I would prefer doing that. 07:31.970 --> 07:37.310 But you could also do the opposite like this and you put the most generic ones on top. 07:38.810 --> 07:41.090 That's depending on what you like most. 07:41.090 --> 07:42.200 But you should. 07:42.380 --> 07:48.820 I try to avoid the first example here of actually mixing having arrows, going both upwards and downwards. 07:49.460 --> 07:55.100 So if you see that this applies to the package level, then that also apply to the class diagram, because 07:55.700 --> 07:57.500 that and we already talked about that. 07:57.680 --> 08:02.570 So you should try to put the classes to our most generic in the bottom or in the top of the. 08:04.760 --> 08:05.270 Very good. 08:05.450 --> 08:08.500 So that was a little bit about package dependencies. 08:09.200 --> 08:13.190 Now we're actually going to do a complete exercise on this again. 08:13.550 --> 08:19.850 So I'm going to give you an example and then I would like you to try to get a sound package structure 08:19.850 --> 08:21.170 for that class model. 08:21.200 --> 08:21.920 So see are.