OK, welcome back.
So now we talked about the evaluation of package structures.
Now I'm going to talk about how we actually derived the dependencies.
I've already mentioned this in a number of times.
I think it would be good to just have a short lecture about just that.
So.
Here we have two packages, and the packages only could only actually have one relationship, and that
is a dependency.
So a package could depend on another package and that is drawn in UML like this and that.
We also mentioned that what we went through this interview, Mel S. So it's a dotted line with an arrow
that shows the direction of the dependency.
So here are the left package is dependent on the right package.
So dependency direction is a product of the included classis relationships.
So if we had four packages, the four packages included in this simple example, four classes, one
class, have an association with the navigability going downwards.
Another class that implies that we also have a package dependency in that direction between those two
packages we have in another association going from left to right here.
That also then, of course, implies the same type of dependency between the packages.
But we can also have a generalization going in that direction.
So you're always follows the arrow, so to speak, and that also then implies a dependency between the
packages.
So both associations and generalizations between classes implies the package dependencies or.
The package dependency is actually the product of that.
So an association without the navigability specified implies actually a double directed navigability.
So we also mentioned that when we talked about associations in the U.
Mel S..
So if you have an association without an arrow, that actually means implicitly that they are arrows
in both associations.
Hence, if you have an agreement and a product and just an association between and we know navigability,
that actually implies double the direction dependencies that are actually in place to dependencies going
in one each in different directions.
So then we have a co-dependency between the two packages.
So would you should try to strive it here is try to get the dependancy association navigability, follow
the abstraction level of the concept and what I mean with that.
So, for example, here the partisan products exist without any agreement, but not vice versa.
So you can have a product and you can have a concept about a product and you can have a concept about
a party without ever talking about agreement.
But it will be very hard talking about the concept of an agreement if you don't already have a concept
about product and parties.
So in that sense, the product and parties are more generic concepts than agreement, and hence you
should try to reflect that in the association.
Navigability and therefore also the package dependancy if you would like to build in flexibility and
modify ability to your models.
So this is probably not a good idea to have a double directed navigability of the associations between
the agreement party and product, because that also gives you double dependency direction on the packages.
Instead, you should probably have this.
So therefore agreement dependent parties and products and the dependency on association navigability
should go from the agreement package to the parties and product packages, not vice versa.
I hope that makes sense and this is something you usually do not maybe during the workshop, but when
you are actually document and start reflecting on the concepts you have found, then you start kind
of fiddling around with the navigability of the associations.
And when you're creating packages, so you see that you actually get double directed dependencies that
you didn't want to have.
So we should try to strive for here.
And this is something very important where you do software development as well as to avoid circular
references.
So a circle of reference could be just between two packages.
So just show you here.
But it could be a little bit more complex that it goes actually through a couple of packages and then
you come back to the first package again.
So of dependencies make packages inseparable and hence reduce the reusability and modify ability of
the model.
So what I mean here is that I cannot actually just pick out one package here from the model because
that means that if I pick out that package and would like to have that in an animal, I need to I need
to take along all the other packages because all packages depend on each other.
So if I don't have that, that I can pick out the package and just the suppliers to that package, so
to speak.
So we should try to do very carefully here is to analyze the associations and the other relationships,
like generalisations over package boundaries and the class as an abstraction level thoroughly.
And then you should try to get the correct association navigability at this point.
So try to get all dependencies to either go upwards or downwards.
So what I mean with that.
So if you have.
The parking structure like this on the diagram and maybe also in your model than with the classes,
because usually maybe when you start off the in, you just surround a couple of classes with packages
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
on B and so on.
You see that you have Aerostar going both upwards and downwards in the same diagram, and that makes
it a little bit hard to analyze for any maybe certain references or to see where the most generic concepts
are.
So I usually put my most generic concepts in the bottom of the diagram.
You can put it in in the top of the diagram as well.
I think it's easier because it rhymes more well with the what it's called layers.
But so you should try to try doing something like this instead.
So in this specific case here, it seems like the package E and the package B are the most generic ones
because they have only actual dependencies going into them.
And then you have package A who depend on package E and B, bad C is also dependent on A, and then
you have C and D, whose only clients to other packages here, they are not the supplier to any of the
packages.
So I would prefer doing that.
But you could also do the opposite like this and you put the most generic ones on top.
That's depending on what you like most.
But you should.
I try to avoid the first example here of actually mixing having arrows, going both upwards and downwards.
So if you see that this applies to the package level, then that also apply to the class diagram, because
that and we already talked about that.
So you should try to put the classes to our most generic in the bottom or in the top of the.
Very good.
So that was a little bit about package dependencies.
Now we're actually going to do a complete exercise on this again.
So I'm going to give you an example and then I would like you to try to get a sound package structure
for that class model.
So see are.