Great last lecture in this section about workshopping.
So when you're doing your diagramming, when you're putting out your classes and your association on
your diagram during the workshop or afterwards, when you're documented, you could do it in many different
ways, of course.
And what would you what you would like to do is to create a diagram that is as easy as possible to read.
People shouldn't have trouble reading it because and understanding just the semantics of of of UML.
They should try to focus on understanding the concepts.
So that is about diagram composition.
So here, I'm going to give you a lot of experience based knowledge.
So I've been developing diagrams for concept models and other types of models as well for nearly six
years professionally.
And you learn a lot.
So here, I'm going to give you some of the highlights.
What do you think about what you should think about when you do this?
So the most crystal clear conceptual model semantically can easily be made impossible to understand
by lousy composition.
So let's take a concrete example here.
Let's take two semantically equivalent diagrams.
So they are expressing exactly the same thing, these two diagrams.
So here's the first one
and here's the second one.
So which one is easiest to understand?
I would probably go with the right one, right, but the thing here to think about is why is that easier
to understand than the first one since they're semantically?
If you just follow all the lines here, you will see that they are equivalent.
So why is that?
It's about patterns, of course.
So give the brain what it wants.
So the brain would like to first, on a phenomenological level, it actually reads the model without
actually reading the what is written inside a concept and everything like that.
Just by the way, you compose your diagram, you actually are saying a lot to the brain before it starts
to actually understand the more detailed meaning of the classes and associations.
So some tricks of the trade here and diagram composition than first one, avoid crossing lines so the
brains get distracted on which route to follow when reading out the semantics from the diagram.
So if you do something like this, the brain has to go a long path before it actually reaches the the
target and end destination.
Sometimes you might need to do it, but at least try to avoid the crossing a line here because the crossing
of lines then at each crossing the brain gets a little bit distracted to see which which way to follow
here.
So instead of doing that, you could have done this, which is much, much easier to understand.
So the association that goes back from A to A is kept close to a, of course, and that association
going from A to B, and it's the shortest path here.
And you don't need any crossing lines.
You should always at least try to remove all the crossing lines.
Of course, there there are situations where you just need to have them but try to to to remove them,
even if sometimes you actually have to do the association a little bit longer path, it might be better
than crossing the lines.
OK, second islands of clusters, so try to place interrelated concepts close and separate them out
from other interrelated concepts.
So if you have something like this, so here's a couple of classes you cannot in this picture see which
classes are actually interrelated or it's much harder to see what this is actually the equivalent of
doing this.
So once we have analyzed the above, we actually see that a DCB are closely related.
They have a lot of associations between each other and FHC are actually quite closely related.
And there's only one association going between the clusters.
And here's where were you as a facilitator.
And documenter needs to be very skilled.
You need to be able to spot those patterns before anyone else is bottom them.
And usually if I'm doing the modelling myself on the workshop, I actually try to fix all those things
as we go along in the workshop because the diagram needs to be easier to understand.
So I just need a bit of a complex example.
But as I said, here's something you really need to train to get to get good at trying to separate class
clusters of all classes.
Try to enforce cohesiveness.
So what I mean by that, so place concepts with close semantic connection, close and separate that
out from other closely related, no matter the number of relations, if they belong together, they
do.
So here we have a couple of classes in the top here, like party agreement, product price, product
address, payment plan.
You probably know that parties have addresses.
It's not that common that the agreement to have an address is the party in the agreement that address
the payment plan is related to the agreement.
And the price of the product is, of course, related to the product, so that it's a good way to start
to separate things that semantically belong together in one kind of loose way.
That also makes the diagram easier to understand and read.
And also make key concept stand out, so highlight key concepts using size and line size.
So the key concepts are the gates into the storytelling and make them easy to find.
So when you start telling your story about your diagram, so when you are going to describe your diagram,
either in textual form or when you're going to actually communicated after you documented it, you usually
start with the key concept.
So you usually start either by, for example, starting about agreements or starting about the priorities.
You can have agreements or product and so on, usually not start with a kind of aggregated, aggregated
concept to an agreement.
So if you have, again, the same classes here, again, party and disagreement, payment plan, product
and product price, there are some of these there are Kanakis citizens in the domain and some of them
are more dependent citizens.
So you could then just note them actually as the key concepts they are.
So you could highlight them a little bit better in the diagram by actually increasing line size and
also increasing the size of the concept.
That's a very good trick that I usually do.
So the main concepts in a couple of places in the diagram, I make a little bit larger and highlight
them so that it's easier to come in to know where to start looking.
Try to be consistent in your lifestyle.
So use the same lifestyle in the complete diagram and do not mix different styles.
That's also to minimize the distraction.
So if you take an example here, we have actually used kind of four different line stars in one in the
same diagram.
Instead, you should use it.
Either do this or you should do that or you should do that.
But pick one of them and stay with that in the same diagram, at least because otherwise also that becomes
a distraction.
The last one I would like to talk about is what I call the client supplier to DeCota me here, so try
to separate out clients from suppliers in the model and try to place suppliers either lower down since
they are more fundamental or higher up because they're considered on higher abstraction, but do not
do both in the same direction.
And what I mean, we clients, suppliers here, if I have in this diagram A, B and C as classes and
I have a generalization between you and C and I have an association between A and B, an association
between CMB, and they also have the inevitability of going to be that means that you should follow
the direction of the arrow, both in the for the associations navigability and also the arrow in the
generalization relationship here and in the case with A and C, then A is the client to C and C is the
supplier to A right for and B again A is the client for B and B is the supply for A and C is declined
for B, B is the supplier for A Forese.
Sorry.
So what you should try to do is to get the clients either below the suppliers or the suppliers below
the clients, depending on a little bit of what you're trying to do to describe.
So do this instead.
So in this case, will have a which in this case is the most specific class because that's a client
of both C and B, and then we have C because C is actually also client or B, and then we have B, that
is the most fundamental class.
And I usually try to put the suppliers in at the bottom of the chart because that holds around very
well with a layered architecture.
When we talked about the layers of abstraction, you usually tend to have the most abstract and more
generic stuff in the bottom of the diagram.
So that's how I usually do it.
Um, and then you should try to do that for the whole diagram.
So the most generic parts are in the in the bottom part of the diagram.
So as I said, these are just rules of thumb.
In the end, every situation is unique, but still those are very that I've found from my experience,
very useful techniques to learn and you should actually learn it.
So they are fluent for you in the same way that if you're fluent in playing piano, you don't think
about actually that you're just putting down your fingers.
You are just thinking about the music you would like to create.
And it needs to be actually the same for you.
When it comes to a workshop, a situation where you do the modelling, you should just have those types
of tools within you.
So exactly directly when you spot the patterns and you know who you are trying to model the concrete
situations, you are trying not to cross in lines, you're trying to separate out concepts are semantically
together.
You're trying to separate Alden's of clusters and so on.
That's something you just do naturally.
So you don't have to think about that because you need to focus on listening on what people are saying
instead.
OK, very good.
So that was the end of the lecture about Dinham composition, and that was actually the last lecture
in this section.
So now we're rushing off into the last section on the whole course, which is about packaging.
So that's when you coming home after workshop.
Usually you're probably not doing the packaging at the workshop depending on your how much time you
have.
But usually when you're documenting the result, you start finding finding the different clusters and
then you package the clusters together in packages.
Barrigan See you there.