OK, very good.
So let's start with you, Mel.
So this is going to be a little bit longer lecture, actually.
We're going to go through the maybe the basic elements within UML.
So we're going to talk about classes.
They're going to talk about the attributes on the classes and instances of classes.
And then in the next lecture, I'm going to talk about associations between classes.
We're going to talk about generalizations between classes, and I'm going to talk about packaging or
classes.
OK, good.
But let's start.
So classes that's actually just maybe a new name for what we talked about so much already in the philosophical
section.
So we have talked about that.
We are having concepts about stuff out in the real world and we are using our language to express those
concepts.
Classes are actually the things you may be using to represent those concepts in our model.
So we can have concepts about, for example, two parties that are making an agreement here, for example.
And I'm just representing the people there because to kind of remind you all that the concepts are something
that we are jointly agreeing on.
So in this situation, we have the concept of a party in agreement and that is represented through each
class is represented the UML Szabolcs with the name indicating the term that we are using for the concepts.
We also talked about in the philosophical section that actually concept don't have a name, but we pick
at least one term to try to point to the concept with.
So here's the class, a class of parties and a class class, a party and class agreement.
So classes then have something that are called compartments.
So compartment holds features such as, for example, attributes that we're going to talk about in the
next slide and compartment can either be hidden as in this latter case with the agreement here or there
could be shown.
But here the compartment is empty, but they are still shown.
You see that.
So that area within the class is called a compartment in UML attributes.
Then the attributes.
They are used to model the non relational properties on the on the concepts so they become attributes
on the class UML.
So again, we have this set of people and they have a joint concept about a car that is pink.
That means that they have a concept of a car and they have a concept of a property called color, and
they think that objects of the concept car could have color and this one is pink.
So that word in Yumba represented asset class with a compartment with the attribute color in it.
Right, so here we have represented the car that could have color.
The attributes instantiation, so in the case where we had the example here, the instantiation would
be pink of the attribute color, right.
Describe the object of the class.
So the objects, a specific car is pink, but the class cars could have the attribute to color.
So here we have that.
So we have this car has a pink color.
So this car points to an object and pink points to an attribute instantiation.
Right.
So attributes could also be said to be of a specific type, for example, date number.
And that is in then in GML stated after the attribute Kolon and then you can specify a type.
So for example, if we have an agreement, one important attribute of an agreement is when it's valid
from that valid from attribute is of the specific type.
In this case, it is a date.
Right.
And it could be valid too, which is also a date.
And it could, for example, have an identify, which could, for example, be of the type of a number.
So of course, dates and numbers are also concepts in some way, but they are also treated as kind of
generic types.
So here we have an agreement with which is a which is a class.
And you smell the class compartment that includes three attributes in each of the attributes have also
stated a type.
So the next election is going to deal with how we conduct workshops to try to elicit concepts and so
on, and when you do that, you usually start off by trying to find the concepts and get them straight
first and then you go into more details like attributes.
The reason for that is also related to talk took part in the philosophical section when we said that
usually you start finding and paying attention to attributes when you have a breakdown case and you
need to start.
You need to first kind of understand the main phenomena here.
To understand where you kind of fail or have success criteria is so obvious then.
So I've said the term big now a number of times and we talked about this massively in the philosophical
section.
So a classifier or a class describes a set of instances that have features in common.
I'm using the word classifier here because classifier is the generic term for a class.
You know, we talked about classifiers when we said what a model is about so that it included classifiers,
events and behaviors.
A class is a specific type of classifier.
So a classifier describes a set, a group of instances that have features in common.
OK, and the special type of an instance that are instances of classes are the ones that we call objects.
So and this is in UML terminology, but it also is very much the same terminology we used in the philosophical
section.
You can see the direct links here going in that direction all the time.
So we said that we have an object here, which is a car, a car.
This car is pink, which is an attribute instantiation of the attribute colors.
You actually used the word instance instantiation, an instance for the attribute as well.
But we call the instance of a of a class like car we call an object.
So that is an object.
And this is an attribute instance.
OK.
The objects in the world are representing you, Mel, as instances of the class.
So I also talked about this when I went through the how you, Mel looks about upon the concept of a
model.
So we said that we could actually have something that was called instance specifications and also a
current specifications and executions so we could actually represent real world objects in the model.
However, the real world objects will not be in the model, but we could represent some aspects on them
so we could represent this specific pink car.
So the pink one and we could also represent the red one.
They then form two different instances in our UML model.
So an instance or an object in this case, this actually applies to most of the instances in UML.
But if we take an object specifically, which is in the instance of a class, is denoted as a box with
an underlined name instead for a class, it's a box, but the name is not underlined.
And also you could, if you like, and you do that usually state the class that it's instantiates after
the kolon.
So the pink one Kolon car says that this is an object which we call the pink one, to make it easier
to reference which actually object out there in the wall that it refers to.
And it is an instance of the class car.
The second one is also an object.
It's another object out in the world.
We call it the red one, but it's also an instance of the same class car.
OK.
Objects could be anomalies, so we can actually have a real world situation here where we have lots
of cars and for the moment or for what we're describing in our model right now, it's not important
to point to a specific car.
We just want to refer to any arbitrary car, maybe.
So then I can just model two different objects, which is which both are instances of the class car,
but I don't put any names on them.
Then they are called anomalies and then I just mean two arbitrary cars.
OK, so the name could be left in blank and that's what I do.
If they are anomalous and I can actually have the other way around so objects can be unclassified.
So I can actually I could model objects before I said that they are instances of a specific class.
And actually this is one of the main features in what is called the object oriented technique that you
usually you can start off just thinking about objects without classifying them.
And then when you start understanding the phenomena of the objects, then you start actually adding
classes and say that those objects are part of the same class and so on.
So this is a very strong idea in the arbitrary, object oriented technique.
So in those two cases here, I have an object which I call X, Y, Z, and I am not with that.
I can call A.B.C..
I can refer maybe to something out in the real world with them.
But I don't I don't have an idea what it is yet.
So you can actually set the class later in the process and that is nothing you need to do from the very
beginning.
And that is a little bit also when you're thinking kind of if I'm doing this top down means that I first
identified the classes and then I can instantiate them if I'm doing it bottom up first, try to identify
what it's going out there in the real world, and then I'll try to classify it and understand it better.
So objects can both be anomalous and they could be the other way around an unclassified
good.
So if we then take this example again.
So here's my car and it's an instance of a car.
So in the same way that a class could had compartments, I can also have compartments on the objects.
So then in this compartment, I could say that the attribute colour, which was an attribute of the
class car in my specific car that attributes instantiation of being pink.
So here's I'm actually represented that whole thing in UML.
So I've said that the attributes Instantiations describes the objects of the class and this specific
object, which is my car is pink.
OK, not so hard I think.
Hopefully so.
Tried to take them in many steps here and then we'll put it together to a little bit larger piece later.
Then there is something called stereotypes, so stereotypes is something it's a construct that he uses
UML to solve this problem.
So what if I want to classify my classes?
So let's say that I have this and I showed you this model already.
So there is a person here which is a class to be used to represent real world persons like this maybe.
And there is a class called Personal Information, which is used to represent real world information
about persons.
Right.
But let's say that I think that they are a little bit different in nature, aren't they?
Then I can actually add what is called a stereotype so I can say that the person here, that class is
a class of natural kinds and this is a class of information so that I can use those stereotypes as a
meta description of the classes that I have in my model to make them.
It's to kind of enrich to semantics a little bit.
So take a concrete example from when you're doing business models, usually using UML, then there are
three different types of stereotypes that could be used.
So, for example, you can say that a class could be a business entity, a business worker or a business
actor.
And there are other stereotypes as well.
But these are three examples.
So business actors represent people or organization or other agents out there that are acting towards
our business, but they are considered to be outside of our business, whereas business workers are
persons, agents, systems, automated stuff going on in our business that helps our actors to deliver
or delivers the value to our actors.
And then we have business entities which represent kind of the resources that we work with or create
or use as a catalyst during this business logic.
And that could be, for example, agreements or products or assets.
So the the actual stereotype is written in an angle brackets, double angle brackets.
However, you can also use icons for stereotypes in your model so you can actually use a symbol for
the stereotype instead, if you like that.
So you can have this this default notation, which is the angle brackets, business entity, or you
can define an icon for that specific stereotype.
And you studies that and say that this is how we show all and business entities or we can use a combination.
So instead of riding out the stereotype name, you can use the icon in the upper right corner of the
class.
So using this way, we can actually describe UML diagrams in many different ways.
Even if they have exactly the same semantic, they could actually look very different and they could
also be more or less expressive them for different groups of people that looking at them.
So, for example, this is standard notation using the stereotypes of a business actor and the business
worker through a two class customer, a salesperson.
Right.
And they have an association.
Or I can use the icon versions of the stereotypes and then I will have a customer and a salesperson.
So semantically wise, these are excellent, even if they could be more or less expressive maybe in
your diagram.
So that's a very powerful notion of UML and is used in many occasions to enrich the semantics of a specific
class.
So summary then on classis attributes and instances and also stereotypes.
So we have said that classes are rendered as a box with a name indicating the term for the concepts
and elements can be stereotypes stereotyped.
So here we have an agreement with an empty compartment, with a stereotype of being in business entity.
And the agreement is a class.
The attributes which are shown in a compartment could also have type.
So in this example, again, the class agreement here have three attributes valid from valid to an identifier,
and they have two different types of the first to have the same type of being a date and the last one
have the type of being a number.
So we can also represent the objects in Gemal models.
So then they are represented as objects specifications and in this case, or they are also rendered
as a box, but with a different set, the name is are underlined and we can optionally all show if they
are instantiating in class.
We can show that after the call, after the name.
So in this case we have a paper which is of the an instance of the class agreement and we can also then
also show the attribute instantiations so we can show that the three attributes from the class are instantiated
in this object and they have specific values for this object.
So here they are divided from the 2nd of April to the 5th of April with an identifier or two, three,
four, five, six, and that is shown in the object compartment.
So what you see here is mainly the most foundational part, or would you mallis about how you represent
you on diagrams?
So that was classis instances of classes, attributes, stereotypes.
Now we're going to go into the other very important thing here, and that is how classes and objects
are actually relating to each other in associations.