OK, but again, that was storytelling, so now we're going to talk about a more specific technique
they can use during the workshop if you get stuck in an area.
So I call it using Ozbek diagrams as an example to exemplify.
So complexity does not mean that is wrong.
So stuff could be quite complex.
I need to be prepared for that.
So just because it's complex doesn't mean that is wrong.
Of course, you should try to simplify as much as possible.
But sometimes complexity is needed.
However, to make complexity more easy to understand, you could utilize examples because when we are
doing concept maps, we are actually mapping the concepts and not the concrete objects.
But as I showed you and you know, you have the possibility to actually also map the objects and that
can be quite useful.
So among the objects of a real world scenario, it's easier to understand complex structures with many
involved in direct, interrelated concepts.
If you first understand kind of the ground zero level, which is the kind of the total picture or one
specific example here.
So take an example of that.
And so this is a concept model about lowed, units that could be part of, for example, a logistics
domain.
So what I'm saying here that there is something called a load unit that could have a power type of load,
unique types, Bitauto power types.
We've talked about UML.
Remember that?
And that could be lowed unit type rule, and that is connecting different types together.
And then different load units could have a load unit connection so they could be connected in some way.
And the connection is actually regulated if it's well, if it's a valid or not valid connection, depending
on if there exists the type rule for the loan units.
And then there are the actual here's an incomplete set of the generalize generalizations of a load unit.
So there are a truck, for example, or a package or a swap, but they are all different types of load
units.
And I can tell you that I can experience reading those type of models.
I will understand this, but I know the people might have a problem understanding it, even if I, I
can directly see that the this is a very powerful model and can be used to model very many concrete
situations.
So it's actually correct, but it's quite complex.
So if you then run into situations, we actually need to create those models to have the flexibility
in the model you would like to have, then you might need to be in place to actually give concrete examples
so that people see that it's a valid way of thinking about it.
So then go down to the most concrete examples here.
So try to be as concrete as possible, like take up whatever you have in the room and start counting
and saying here's a cup or whatever it is.
So be down to serve your example.
So let's say baseload units here.
You actually take a few examples.
You have SWAC body, you have a truck and you have a package right
there.
You're saying that we need to have some way of knowing how we can actually connect different types of
load units together.
So could I connect a package with a swap body?
Yeah, let's say that's fine.
Could I connect a swap buddy to a truck?
Yeah, that should also be OK.
But could I connect the package directly onto a truck?
Probably not.
So you see that the way how you connect the different types is something that is important.
And that was the room that I showed you in the concept model.
So here you can explain to people we need to know whether different connections between load units are
OK or not, depending on some type of regulation framework.
OK, so then the specification part of the load units here so we can have then this rule, which is
then exemplified just as I as I wrote here, there's a swap body and truck.
Yeah, that's one rule.
Let's call it rule one, which is of the type load unit type rule.
OK, that means that the load unit type truck could be connected to the load unit type swap body.
OK, so here we have the two power types of two instances of the power type and then we have another
rule saying the rule to load unit type rule.
And that's the that's the class.
We're saying that packages could be contained in swap bodies, OK, and that means that the swap body
load union type is connected via a rule with the low union type package.
Very good.
So then I have a concrete configuration.
So if that was my specification side, so before I even got a specific truck, I talked about the types.
So he drove me back to the discussion of power types that we had when we talked about Yamal in general.
So then let's say they have a specific truck, one that's my truck.
And on this T1, I have one swap body, S.B one.
Yeah.
And so I have a connection between my truck and this specific swap body.
And I also in this specific spot body, have one package, P1.
So I also have a load unit connection between the swap body and the package.
Right.
And then actually the swap what I had another package as well as I actually had two packages in this
swap body, so I have another load unit connection.
We'd package P2.
OK, so that aspecific configuration.
Well we like to know here if this configuration is a valid configuration according to the specification,
and then we need to find the actual connections here.
So is this a valid configuration?
Yeah, there's something called a truck and we have a prototype for that load.
Unique type truck.
That's fine.
That's directly in the model.
So here's the prototype.
And we have the power type Facebook body and power type for truck for package as well down there, and
we see that the first load, unique connection here between our truck and the specifics of our body
is actually correct, because there is a rule in the specification saying that you could combine a load
unit type truck with the load unit type swap body, and hence that connection is OK.
And there's also the load utility package, which both package one and package two are the type of and
there's also a load unit type rule specifying that you could have a connection between swap bodies and
packages and hands.
Those two connections are also correct and hence the whole configuration is correct.
So you see now in this example, and this is an object model that you can reason about, that this is
the way the world actually looks already in this domain, actually sees this knowledge and hence the
model that we had, which was a little bit more complex.
That is correct.
So the question then is, is this now a little bit easier to understand?
So here we see that we have the specification part of it to his right and we have a configuration part
to the left and we see that the connection goes between the power type and the actual type of the load
unit, the actual class of the load unit.
And there is a connection between the actual configuration back to the specification that validates
and the correctness of the connection.
So I think that those two in combination, the omic diagram that you can then right up on the whiteboard
while you're doing this modelling or you write it as a separate diagram and have in your model as well.
So you can have multiple diagrams in the same model as we talked about, makes the class diagram easier
to grasp and understand if you come into complex situations.
So that was a concrete example how you can use objects, diagrams during your workshop and also when
you document the model or the diagram you're doing.
So I usually actually tend to do on big diagrams, on complex parts of my conceptual models and ship
them in the documentation as well so that everybody can see how it actually works on the ground level.
But again, that was using only diagrams.
So now we're rushing to pattern recognition.