OK, very good.
So that was the first year lecture will be talked about classes, instances and attributes and classes
and stereotypes.
Now I'm going to go into associations and links between classes and between objects.
So we start off with associations.
And yet again, I think you will see that there are a lot of kind of connections going back to the section
about the philosophical foundations here.
So we said that the people here are they have the concept of people that are making an agreement and
relational properties becomes relationships between classes in your mouth.
So here we could, for example, have two classes represent the salesperson's, salesperson's and customers.
And if we think that there are some type of relationship between those two classes, that is going to
be represented as an association.
ECOMIL and Associations is the most common relationship that is used in class modelling.
And we're going to use it all the time.
And it's shown as a solid line between two classes.
So if you see a solid line between two classes, then you see an association.
Good, so typical relations star model with associates.
And as I said, most relations are associations are, for example, you have an agreement that refers
to a product, you have a salesperson that is using the product and trying to sell it.
And you might have a process or sorry, product owner and a three solid lines.
Here are all associations between those different classes.
So association ends, that's the end bits of the association, as they are called, the association
ends.
So we have the solid line and then each association have to association ends.
Each end could have multiplicity.
So in this case, between the party and the agreement, I can state a multiplicity on the parties side
here and the multiplicity on the agreement side here.
And that's the two association.
And so this association.
So the multiplicity regulates which type of object constellations that are possible using this association.
So in this case, in this example, it says that an agreement must have at least one party, but a party
does not have to be involved in an agreement.
So the one on the association and to the left here is indicating that it needs to be at least one object
of an instance of the class party connected to every agreement.
But this zero on the other one state that it doesn't have to actually have a party that doesn't have
to have an agreement.
The Asterix is showing that it could be multiple.
So you're saying one or many or zero or many.
So classes could have multiple association between each others and the associations could have rule
names.
So take this example with party in agreement.
Again, we can actually have maybe three associations between the three between the two classes, and
they might have multiplicity, as we just saw, but they can also have role names.
So here we can actually have one association saying that an agreement had one party that is the client
have another party, which is the supplier, and could have one or multiple parties.
That is in the role of being manufacturers.
OK, so that without its UML terminology, that is association name, have an association and have a
role name, which in this case is clients apply to manufacturers
and it specifies the role the class plays in the context of that specific association
association and could also have something that is called navigability and navigability is shown as an
arrow.
But it's an open arrow because we come to that.
So there is a closed arrow, but that is not actually an association.
And then it's a generalization.
But if it is an open arrow, then it shows the navigability of the association.
So navigability shows and specifies if a class knows about this relationship.
So we can say that an agreement knows about the product, so to speak, but the product does not know
about its agreement or agreements that may refer to it.
Maybe so that's a way of saying Canale, I know more than you do or I need you in some way.
I'm a client or a supplier in terms of concept to concept wise.
So navigability is actually quite important.
But usually you don't start by having and stating each association is navigability.
But once you have your concept model, your first sketcher we've kind of done, then you might go into
and try to specify each association a bit more.
But when you set it up, you probably just have to draw the solid lines.
So if and if you don't have any arrows, if it's just a solid line, that implies that both hands are
navigable.
So that's a shorthand for describing the arrow in both directions.
It could be a little bit confusing about the direction of the arrow here, because there's actually
two quite different meanings of a direction of an area, UML.
But when we're talking statically, which we do here because it's a static relation, we only saying
that those two talking concepts have some type of an association.
There's no dynamics going on here.
Then we say that the agreement concept depends on the existence of the product concept.
Not wise for us.
Right.
So the the the direction of the arrow is implying a dependency direction.
If we're talking about then in UML as well, we can do an activity diagram, for example, and then
we will have an activity like define product, which is done before we write an agreement.
Then the dynamic meaning of an arrow is actually chronological meaning.
But so we we first define a product and then we write an agreement.
OK, but you maybe see the here as well, so.
The agreement depends on the product and not vice versa, but we defined a product before we define
the agreement and that's that's logically right.
But it could be a little bit confusing if you're if you're going between diagrams are showing some dynamic
flow and diagrams start showing static things UML.
But we encountered models.
We only talking about the static thing.
So it is a dependency relationship.
We are modeling, not a behavior one.
So if we put this together for associations, we'll have, for example, like this.
So we have an agreement with three associations to the concept party and an agreement is regulating
the use of one or many products and product.
A party is the owner of a product.
So here we have used actually a number of associations we've used navigability.
We used your name and you also see this a little bit, our road that is filled on the association.
That is just a notation you can use in your email to simplify the how you reading the model.
So what is regulating the use of the arrow?
That is the reading direction.
That's and that is maybe easier to say that a party owns a product so you don't miss mistakenly say
that a product is a party.
Right.
So it's a reading direction.
Very good.
So that was associations, so let's go into what links are then maybe you've already figured it out.
So links actually specify specific relations between objects.
So if associations was between classes and hands, concepts, links are real world relations between
objects.
So we have this situation, the Romeo who loves Juliet and Juliet, who loves Romeo.
And that would actually we talked about that in the philosophical part and the philosophical section
that is denoted very similar directly in your mouth like this.
So you have an object.
Romeo are the class person.
You have an object, Juliet of the class person.
They have two links between each other, which is loves, and they are each other's agents in those
two links.
So the links are also shown as a solid line between two objects, but with the same thing.
When we saw about instances like objects or classes, the name was underlined.
And that is actually the same thing here when it comes to links so loves.
If we are stating the name of the association that is instantiated will be in an underlying name, UML.
So and that is I already said that now those links are actually instances of associations.
So take this example.
We have a person that can refer to one or many other persons in association on a class level.
And the association here is called Loves.
That is actually the class diagram.
And below here is an object diagram specifying a specific love relationship.
Right.
So here we have Romeo loves Juliet and Juliet loves Romeo.
They are two instances, a person, as we said, and they are actually instantiating this association.
So the objects are instantiating the class and the links are instantiating the association.
Quite logical, isn't it?
So an association declares that there can be links between the objects.
It's not saying that there are links.
It says that it can be links between the objects.
So you usually use object diagrams to clarify real world situations and scenarios.
So it's good to use when the classifications becomes more complex.
So this is a very simple one, but I will show you later on the next section when we are talking about
how you actually do this in practical workshops, much more complex scenarios.
And here's a real wars scenario for this.
So we have a child with parents.
And the real world scenario is that a child called Charleson is charcoaled.
Sarah both have the same parents, Claire and John.
OK, so that object is objects and links and above we have classes and associations and they are all
the instances of each other.
So I've said it now a couple of times that you can actually instantiate an association.
It becomes a link.
That means that in Jhilmil terminology, we think about this on one metal level up and saying we are
saying that a class is a classifier, an association is also a classifier because they could be instantiated.
And hence, what if I need to describe attributes for the association?
You can actually do that.
So an association can actually have attributes in what is called an association class.
So you can say that a person have an association called employment in a company, but you actually might
want to talk a little bit more about this employment so you can actually state that the employment is
in association class and have a start when he started when he ended in the salary and so on.
So association classes are shown as regular classes, but then they have a dotted line that connects
them to the association that they describe.
However, you could describe it like this, but if you think that that looks a little bit complex,
you can instead use this.
So that is pretty much saying the same thing, that a person has an employment with a company.
So you can use both annotations depending on what do you think is the easiest one.
Then there is a type of associations that are a little bit strong, more stronger, and they are called
Composition's, so you can actually model compositions of objects.
And we talked about that also in the philosophical part.
So when we think that objects are composed of all the other other objects, we talked about Mariola
theology.
If you remember that, then that is modelled in humans as what is called aggregations.
So typically here we have this table and we say that the table consists of four legs or one, two,
four legs and a surface and the top, which is the top and the top and the table legs are also connected
in some way.
So typically a pretty instance is only attached to one whole instance at the time.
Right.
The composite aggregate are shown as a solid black diamond at the association and for the whole class.
So in this case, the solid black diamonds are showing that the table is aggregating the top and the
table legs.
OK, but there is also an alternative, a little bit newer way of to model this, which are called compositions.
So you can have composite classifiers in UML now and since 2.0.
So instead of actually showing the table with a table and top of three different classes with an aggregation,
you could show like this was saying that we have a class table and within that compartment you can actually
show the composition, saying that within this table it got four legs, one to four legs, table legs
and one surface, which is of the type top class, top and the table legs and the top are connected
and they are both an aggregate aggregated within the concept table.
So that's another way of representing it that some people might think is more intimate or some people
might not.
I just wanted to show you that.
Okeydokey, so let's summarize classes sorry, associations and links then.
So we have said that an association are shown as a solid line between two classes and name and reading
direction could be shown.
So an agreement has a party and I can have written directions in both directions if I like on association
as well.
So association ends could show multiplicity role names and navigability.
So those are three things that you can show.
An association and an association have at least two ends.
Right.
So here we have a real name client on the party side for the agreement.
We have multiplicity on both the parties side.
On the agreement side, we have multiplicity on the address side for the party.
And also the navigability saying that the party knows his address, but not the other way around.
The party concept is dependent on the concept and not the other way around.
And we can also show a composite aggregation that we're saying that a party actually owns its addresses,
if you like, if you think that.
So this is, of course, related to which type of conceptualisation you have.
Then we can show an object diagram with objects and links which are actually done instantiations of
both the classes and the associations.
So here we will have one party which we call Acme Inc, which is involved in two different agreement,
a one and a two, and it's declined in both the agreement.
So that's two links of the association.
We have a bar and the Acme Inc. have two addresses as well, one visiting address and one billing address.
So links between objects, which are instances of associations, are also shown with solid lines between
the objects.
And if you also show the association name, that will also be underlined.
And there are many ways to tell a story, of course, and we've shown that it depends on which class
of which conceptualisation to have about the real world, how you will actually model it, of course.
But so there's many different ways of modeling the same domain.
And that depends on what the experts think is important to consider important here.
So I can model like they're saying that a parent might have child sooner than a child, might have up
to two parents.
But I can equally maybe say this, saying that a person has an association to other persons and in that
association they are either parents or children or I can just model it saying that a child have an attribute
of a father name and a mother name, depending on which type of domain in which type of system I'm doing
now and watching what is important in our current analysis, the different kind of details in this could
be used.
So and that is most important because there are no true and false here.
They are more like if it's usable or not in our current situation and you don't want to have too much
details if you don't need them.
But in the other way around, you don't need you don't want to have two less details to be able to express
what you need.
Very good.
So that's the end of that lecture.
And that was about associations and links.
So now we're going to talk about the other specific relationship called generalizing generalizations.