OK, good.
So now we're really off running, so let's be a little bit more formal now, we talked about generically
while AMOL is about on a kind of high level and why we model and also what a domain models, but a little
bit more formally than what is a model and how can you describe a model?
I'm going to use the kind of definition that is used in UML.
And as I said, we're going to use UML for the rest of this course.
And the next lecture I'm going to start talking about or do you Amalia's.
But before we do that, let's talk about how you will look upon the concept of the model.
So according to your email, there are three categories of elements in a model, and the three categories
are classifiers.
Events and behaviors, so those are the top level three categories of all the things that are included
in the model, and then there could be loads of different subtypes of those.
So each of those major category models, individuals in an incarnation of the system being modeled.
So now we're starting to be a little bit tricky maybe here by what is meant by that is saying that,
for example, the concept of a car is modeling an individual in the system being model.
And in this case, the system being model could be a business, for example, so it doesn't have to
be an I.T. system.
We talked about that already.
So a car could model individual cars in a vendor, for example, business selling cars.
Right.
A sales event models individuals of typical sales going on in that business.
And the sales process is describing individual executions of processes in that business.
Right.
So the model includes so sorry, the model, the models, individuals in an incarnation of the system
being models and incarnation is one instance of a system.
So and that is also quite important to think about that the system is actually something you instantiate.
So think about, for example, McDonald's or something.
So there are thousands of McDonald's restaurants.
Each is an instance of a McDonald's restaurant.
But you must be able to describe the system of a McDonald's restaurant separately and then you have
incarnations of that in all the restaurants.
So classifiers first, then a classifier describes a set of objects and an object is an individual thing
with the state and relationships to other objects.
So you see directly here that this ties back directly into what we talked about in the philosophical
foundation.
And that's why I think that it was important to go through that before we do this, because when you
see directly the kind of links that go out from this domain of kind of system development and business
development into the philosophical foundation, and here's kind of cross-functional science going on.
So a car is a classifier and it describes a set of objects, for example, two cars.
OK, events, an event describes a set of possible occurrences.
So in the same way that a classifier describe a set of objects, events describe a set of possible occurrences,
an occurrence is something that happens that has some consequence within the system.
So that's an immediate kind of thing that happens, that stimulates the system in some way or affects
the system in some way.
So then there are a set of occurrences.
So, for example, maybe those are two types of accident occurrences.
I don't know, maybe maybe the the second one is might might not be an accident here, but yeah.
See, my point and we can have an accident event that describes those two accident occurrences.
And lastly, we have behavior.
So exactly in the same way here, behavior describes a set of possible executions.
So an execution is performed.
Sorry.
So an execution is the performance of an algorithm according to a set of rules.
So an example, again, this is one execution.
First, you do a they you do be another execution would be first you do a but then you do see.
Right.
So those are two ways of executing, for example, a process.
So those are two set of possible execution, although they form the set of possible executions, those
two together.
And the behavior, for example, a business process is describing both the possible executions here.
So the behavior will be described as A, then B or C, right.
But an execution can never do or it does either either B or C.
So the two possible executions here is a plan B and an aide and C.
OK, so you see that they are very alike, here are the classifiers, the events and the behaviors.
So moles and this might be very obvious, but it might need to be stated because sometimes you actually
do this mistake.
And quite often I would say some models do not contain objects, occurrences or executions because those
things are the subject of the models, not their content.
So I started off this whole section describing that is very important, that you differentiate between
the subject being model and the model and hence the model never actually contain objects, occurrences
or executions.
They are part of the subject.
So you have subjects out there.
You have models including the classifier of events and behaviors.
However, and here's where it usually goes wrong.
A model can actually model aspects of individual objects, events or behavior.
So, for example, we can have this specific occurrence of an accident that is going out in the summit
area.
And we can model that specific occurrence, not just the event, but actually the occurrence.
We could model some aspects of it and some aspects could hear, for example, B, that we say that the
accident type is a banana slip and the time of the accident was the 11th of March 2011.
That is then called an occurrence specification.
So that specifies a specific occurrence out in the real world.
And then we can also then have the actual event.
So we have an event.
We could have an occurrence specifications.
They are part of the model and then we have the actual occurrence out there.
But the occurrence will be complete, whereas the model will always be incomplete because it's only
showing aspects of the subject matter.
So, for example, the model will never feel pain when you fall somewhere after your slip, right?
So the pain is only precedent in the subject area and model, of course.
OK, Mary may be too obvious, but as I said, I think it's very important here to be crystal clear
about this.
So value specifications or current specifications and execution specifications, model individual objects
of Currentzis and execution within a particular context, so we can actually exemplify aspects of the
real world, objects of the real world, occurrences like this example and of the real world executions.
And they they are part of the model.
So next is a diagram, the model?
No, it isn't, actually.
But many people are actually almost using them as synonyms, but they aren't actually.
And I will show you why.
And I myself actually do use them as Cinnamon's sometimes.
So maybe you have to to live with that.
So diagramed model distinction.
So the model is the think about it just like the database or the store of the complete offer, recursively
composed set of elements.
So elements are, for example, an event or a classifier behavior that describes the system.
So it's the complete set of all the things that we need are in our model.
That's the model.
So think about it here.
This is not a diagram, but it's kind of a conceptual view about the conceptual model, including some
elements.
Write a specific diagram is showing an aspect of that model.
So the first diagram here up to the left might be including three of the elements.
A second diagram might be three, including the same element, one of the same elements from the first
diagram and then two other elements and the jetton on the third diagram and actually also include that
first element and then two other elements.
So you can actually then use diagrams to specify specific aspects that you would like to maybe highlight
for some reason.
So those are maps or diagrams.
But the good thing about a model is that you have this store, so you don't actually have to rewrite
all the diagrams all the time because it's stored in the complete model and then you can just create
and compose diagrams out of that model.
So bear in mind, as I said, that we also use that we often use the term model as a shorthand for diagram
maps, subset of model or the other way around that we use trying and we we mean model.
And just so you have that in mind, because it happens a lot.
So people are talking about conceptual maps, for example, and then we might say conceptual model,
and sometimes it's a conceptual diagram, but maybe I'm meeting the same thing in all three terms here.
So, for example, I might have a model, including a number of elements.
And actually the diagrams as such are part of the model as well.
So I might have one diagram showing one aspect of some of the elements here, some of the the classifiers
or concept party agreement, all agreement and product, and might have a completely different diagram
showing a completely different aspect.
In this case.
It's the packages and I'm talking about packages later on.
They are kind of subdomains within this.
I mean, the subdomain of an agreement, product and party.
So those two diagrams are describing different things, but they're part of the same model.
OK, makes sense.
I wasn't very good, so I missed the third lecture.