OK, good.
Last section, so now in this section, we're going to talk about packaging your model.
You're coming home, you're doing your workshop now it's time to document it.
So now you probably have a large set of classes that you found during the workshop and you didn't maybe
didn't have time to start to differentiate them out in different clusters and in packages and in smaller
subsets because you were focusing on actually getting everything down.
But now you will, like, make your model as readable as possible.
You would like to make your model as readable as possible.
So then you can use a technique called packaging so you can actually divide your model into smaller
chunks and then you can actually document each chunk and they can also document the chunks, so to speak,
on a larger level.
And the chunks are called packages.
So this whole section is about packaging your model.
So I'm going to give you an overview about packaging.
I'm going to give you guidelines how you actually do packaging.
We're going to talk about how you evaluate the package structure, your own or somebody else's.
And we're going to talk about how you how you derive the dependencies between the packages.
And then we are going to have some exercises where actually you are packaging a model yourself.
Very good.
So let's start with this overview lecture.
Divide and conquer Julius Caesar.
This is what it is about.
So you have two large set of elements with too much detail and you need to start the divided to be able
to conquer the complexity.
And we are using packages, so packages and I've already shown this in you mail, what kind of notation
it is for it, but your package, smaller bits into cohesive, larger homes, which together makes up
the subdomain.
You can then speak about and refer between the subdomains.
And what do I mean by that?
So what I mean with cohesive, larger holes.
So if you think about Lego, I don't know if you done any Lego recently, but in Lego nowadays, the
small Lego blocks are actually divided into small plastic bags with a number on them and they're not
divided.
Saying that we have all blue blocks here and all red blocks here, an old yellow box here, for example,
they are divided because the blocks within each plastic bag have some thing in common.
They are used to achieve a function usually, and that means that they are cohesive.
So they have something in common that they are building up some larger hole.
So maybe the stuff in this bag, this will be the engine and the stuff here will be the chances, for
example, of a car.
So packaging is used to deal with the complexity in a model by decomposing it into smaller chunks,
that's quite easy to understand.
So here's how it looks.
So we have X and Y, we have A, B and C, and let's say that X and Y are more more cohesive with each
other than A, B and C, then you can create two packages and the package will also have a dependency.
OK, nice and easy.
An example, a little bit laundry example, let's take asset finance business of some kind.
So here you might have products in the bottom.
So we have parties.
We have agreements that are connecting the parties with the products.
We have receivables.
We have payables.
We have invoices.
We have supplier invoices.
We have incoming payments.
We have outgoing payments.
So these are all subdomains, so to speak, in this larger domain.
And each of the packages here actually includes quite large set of classes usually.
So when it comes to parties, for example, you're talking about different types of parties and billing
addresses and so on.
When it comes to products, you have the products and the different pricing and the parameters of the
product products.
When it comes to invoices, for example, you have invoices and invoice lines and.
And different types of currency conversion between different emotions and so on, so there are each
subdomain could be quite complex in its own.
And hence if you did a complete conceptual map of that complete domain, that will be a very complex
one.
So then it's a very good thing to use packages to divide and conquer here.
So what you also see here is that we are actually looking at the package diagram on an higher level.
So that could be used to actually hide the details in the class diagram.
But still, we are getting quite much knowledge from the package diagram.
So we're actually getting the the collected dependencies between the different elements within the packages
with each and with other elements in the other packages.
So we can actually directly see here which subdomains there are dependent on, on other subdomains.
So that was the first overview lectured about packaging.
Now I'm going to give you some guidelines how you actually do it, and then we're going to run into
how we evaluate packages.
Good.