WEBVTT 00:11.030 --> 00:11.990 OK, good. 00:12.120 --> 00:13.340 We're making good progress here. 00:13.730 --> 00:16.660 So now let's talk about how you evaluate your packages. 00:16.670 --> 00:20.990 So let's say that you come up with the first idea or sketch about which packages you think that you 00:20.990 --> 00:27.160 should divide your model into or that somebody else have made a packaging structure of a model. 00:27.470 --> 00:27.980 This does. 00:28.430 --> 00:31.120 So this applies to software modeling as well. 00:31.130 --> 00:33.010 So it's not just a conceptual modeling. 00:33.020 --> 00:37.710 So this could be applied directly to, for example, Java packages if you program in Java. 00:39.050 --> 00:41.210 So how do you evaluate packages? 00:42.500 --> 00:47.660 One, a package should optimally include somewhere between five and nine classes, and that has to do 00:47.660 --> 00:55.100 with human beings and not anything with AIJA systems that if there are more than that, then you start 00:55.100 --> 00:58.940 actually losing context in your mind. 00:59.060 --> 01:03.300 So you have a harder time to to have all the stuff in your hand at the same time. 01:04.130 --> 01:09.890 So that's kind of a good rule of thumb that try to keep your packages around five to nine classes. 01:10.070 --> 01:11.540 That could be a little bit less. 01:11.750 --> 01:14.180 Having just one class in the package is a little bit odd. 01:14.510 --> 01:20.620 Maybe having 18 is maybe fine, but it seems to be a little bit too large package. 01:22.610 --> 01:30.170 So so this is probably not such a good packaging because you have very many classes in one package and 01:30.170 --> 01:32.180 then one just one in the other one. 01:32.510 --> 01:34.610 And here's probably a little bit better. 01:34.610 --> 01:42.470 So you have like five in the lower one and seven in the upper one avoid islands. 01:42.470 --> 01:43.780 So classes in a package. 01:43.940 --> 01:48.660 So if you have a package that look like this, then probably something is fishy. 01:49.130 --> 01:55.010 So instead of having that, you actually have here a very natural probably two packages because you 01:55.010 --> 01:57.700 have two sets of classes that have nothing to do with each other. 01:58.490 --> 02:00.290 So then you should probably try to do that. 02:00.290 --> 02:07.310 Instead, the classes inside the package should be more functionally and semantically related to each 02:07.310 --> 02:09.830 other than with other outside classes. 02:11.060 --> 02:19.700 So here I have an example of where actually the red class here seems to be more related to the classes 02:19.700 --> 02:22.020 in the lower package than in the upper package. 02:22.040 --> 02:27.260 So then you probably need to move that class and then you get a better cohesiveness. 02:27.260 --> 02:32.690 And you also see that you reduce the number of associations crossing the lines from three to one. 02:35.960 --> 02:42.410 A class were used by several classes in different packages to probably not be located in one of its 02:42.410 --> 02:43.550 Clines packages. 02:43.610 --> 02:45.290 This is just a rule of thumb. 02:45.800 --> 02:47.840 I'm not saying that it should always be that. 02:48.200 --> 02:49.450 But consider this. 02:49.850 --> 02:56.570 So you have two packages, three packages, whereas two other packages are reusing one class from the 02:56.570 --> 02:57.380 first package. 02:57.380 --> 02:58.820 But it's another class. 02:58.830 --> 03:02.870 There's also within that package reusing it and it seems to be using it in the same way. 03:03.350 --> 03:09.560 Then you could consider actually doing this and breaking it up to make this more generic package that 03:09.560 --> 03:11.860 is reused by three other packages. 03:14.540 --> 03:20.390 So packaging problems tends to be what is called like a fuzzy logic problem, because you're trying 03:20.600 --> 03:28.370 to get the best possible optimal fit in a situation that means that you can probably not get that in 03:28.370 --> 03:29.750 just one dimension. 03:30.020 --> 03:34.950 So you have to strike a balance between different dimensions. 03:35.510 --> 03:42.020 So, for example, the package should have high cohesiveness and not too many classes and high collaboration 03:42.020 --> 03:45.340 with Eterna classes and low collaboration and external classes and so on. 03:45.530 --> 03:52.250 So you could probably not strike the highest value on any of those axes, but you should try to have 03:52.250 --> 03:54.890 the best optimal fit on all the axes. 03:57.020 --> 04:00.440 So packages are seldom defined based on Syntex only, of course. 04:00.980 --> 04:05.290 So semantic and psychological aspect needs to be taken into account as well. 04:05.900 --> 04:10.910 So in the end, the most important factor to get a good package structure is knowledge about the domain 04:10.910 --> 04:16.630 semantics because the package structure should follow the expert intuitive borders of the domain. 04:17.570 --> 04:18.920 So take an example. 04:19.160 --> 04:21.650 The package structure should follow the experts as a set. 04:21.660 --> 04:27.320 So if you have this so we have a package with order online customer and product and then we have other 04:27.320 --> 04:31.420 packages would address and contact person and another package with product, price and currency. 04:31.820 --> 04:32.910 What's the problem with that? 04:33.590 --> 04:40.460 Yes, there is a problem because probably the customer and the product is more related to the to the 04:40.460 --> 04:41.840 lower packages here. 04:42.080 --> 04:43.760 So you should probably move them out. 04:44.270 --> 04:47.840 Even if you see, you also reduce the number of associations here. 04:47.840 --> 04:53.690 But you see directly that order and order line is much more intuitively packages together and product 04:53.690 --> 04:56.530 and product price and so on and customer numbers and contact person. 04:57.080 --> 05:02.960 So in the end, it needs to be you need to have a semantic. 05:03.100 --> 05:09.370 Aspect on this as well, so you need to try to actually understand how they relate semantically and 05:09.370 --> 05:11.240 then you will see which packages you have. 05:12.400 --> 05:17.500 So you have to practice and practice and practice to learn the art of packaging and modeling to Italy. 05:17.770 --> 05:24.740 That is something that you really need to practice because you won't do this the first time and not 05:24.740 --> 05:30.490 the second time, maybe the tenth time, at least when you're done it 100 times, then you start feeling 05:31.480 --> 05:33.360 that this is something you know how to do. 05:33.970 --> 05:43.000 So this is again, an advice that you start tried to do this on as many models that you can get hold 05:43.000 --> 05:50.510 of and as often as possible and try to think about what is the most intuitive packaging of the model. 05:51.760 --> 05:52.330 Very good. 05:52.600 --> 05:59.080 So that was the end of this lecture when we talked about how you evaluate package structure that you 05:59.080 --> 06:01.840 have either done yourself or a package structure. 06:01.840 --> 06:05.200 Does somebody else have done next? 06:05.200 --> 06:07.480 Actually is going to be about package dependencies. 06:07.930 --> 06:08.560 So you there?