OK, good.
We're making good progress here.
So now let's talk about how you evaluate your packages.
So let's say that you come up with the first idea or sketch about which packages you think that you
should divide your model into or that somebody else have made a packaging structure of a model.
This does.
So this applies to software modeling as well.
So it's not just a conceptual modeling.
So this could be applied directly to, for example, Java packages if you program in Java.
So how do you evaluate packages?
One, a package should optimally include somewhere between five and nine classes, and that has to do
with human beings and not anything with AIJA systems that if there are more than that, then you start
actually losing context in your mind.
So you have a harder time to to have all the stuff in your hand at the same time.
So that's kind of a good rule of thumb that try to keep your packages around five to nine classes.
That could be a little bit less.
Having just one class in the package is a little bit odd.
Maybe having 18 is maybe fine, but it seems to be a little bit too large package.
So so this is probably not such a good packaging because you have very many classes in one package and
then one just one in the other one.
And here's probably a little bit better.
So you have like five in the lower one and seven in the upper one avoid islands.
So classes in a package.
So if you have a package that look like this, then probably something is fishy.
So instead of having that, you actually have here a very natural probably two packages because you
have two sets of classes that have nothing to do with each other.
So then you should probably try to do that.
Instead, the classes inside the package should be more functionally and semantically related to each
other than with other outside classes.
So here I have an example of where actually the red class here seems to be more related to the classes
in the lower package than in the upper package.
So then you probably need to move that class and then you get a better cohesiveness.
And you also see that you reduce the number of associations crossing the lines from three to one.
A class were used by several classes in different packages to probably not be located in one of its
Clines packages.
This is just a rule of thumb.
I'm not saying that it should always be that.
But consider this.
So you have two packages, three packages, whereas two other packages are reusing one class from the
first package.
But it's another class.
There's also within that package reusing it and it seems to be using it in the same way.
Then you could consider actually doing this and breaking it up to make this more generic package that
is reused by three other packages.
So packaging problems tends to be what is called like a fuzzy logic problem, because you're trying
to get the best possible optimal fit in a situation that means that you can probably not get that in
just one dimension.
So you have to strike a balance between different dimensions.
So, for example, the package should have high cohesiveness and not too many classes and high collaboration
with Eterna classes and low collaboration and external classes and so on.
So you could probably not strike the highest value on any of those axes, but you should try to have
the best optimal fit on all the axes.
So packages are seldom defined based on Syntex only, of course.
So semantic and psychological aspect needs to be taken into account as well.
So in the end, the most important factor to get a good package structure is knowledge about the domain
semantics because the package structure should follow the expert intuitive borders of the domain.
So take an example.
The package structure should follow the experts as a set.
So if you have this so we have a package with order online customer and product and then we have other
packages would address and contact person and another package with product, price and currency.
What's the problem with that?
Yes, there is a problem because probably the customer and the product is more related to the to the
lower packages here.
So you should probably move them out.
Even if you see, you also reduce the number of associations here.
But you see directly that order and order line is much more intuitively packages together and product
and product price and so on and customer numbers and contact person.
So in the end, it needs to be you need to have a semantic.
Aspect on this as well, so you need to try to actually understand how they relate semantically and
then you will see which packages you have.
So you have to practice and practice and practice to learn the art of packaging and modeling to Italy.
That is something that you really need to practice because you won't do this the first time and not
the second time, maybe the tenth time, at least when you're done it 100 times, then you start feeling
that this is something you know how to do.
So this is again, an advice that you start tried to do this on as many models that you can get hold
of and as often as possible and try to think about what is the most intuitive packaging of the model.
Very good.
So that was the end of this lecture when we talked about how you evaluate package structure that you
have either done yourself or a package structure.
Does somebody else have done next?
Actually is going to be about package dependencies.
So you there?