What is an "Instance"?

[MaXyM]

As promised in another post, here it is...

When modelling systems and application programs, this is fairly clear.
"Car" is a Classifier, "BMW 318i" is a (specialised) Classifier, "BMW 318i with plate # XXX 888" is an instance of the Classifier BMW 318i".  We implement Classifiers with Classes and Instances with Objects.  Everyone agree?

Probably I'm the one who doesn't
"Car" is a class. If you want to model a flow with instance of this class, then you create instance of this one, let's say "BMW 318i". In this case "Car" is a classifier of "BMW 318i". You can create more instances of this class, each one with another plate, or color etc.

BTW in your example, plate number should be an attribute. Even BMW 318i has a plate (empty). Of course until you aren't going to distinguish vehicles with plates and without. But probably even in that case I wouldn't go for different classes (car with or without a plate)

If you want to go for more generalization, you we can add 'vehicle' class. Then:
- Vehicle is a class
- Car is a class inherited from Vehicle class
- physical existing car BMW i318 (doesn't matter with plate or without) is instance of Car class, speaking another way: Car is classifier of instance of BMW i318


Let's take another example: server deployment. Let's imagine Device element which describes a server. It has attributes RAM, IP, CPUs etc.
But, since deployment diagram contains physical and (to be) existing elements, you cannot put device element on it. You have to put instance of the device, setting up attributes defined in it's classifier, because once you materialize the server, it will have some CPUs, some amount of RAM etc

IMO classifier is just a term describing relationship between instance and its description. This relationship in UML can be applied not only to classes and its instances (objects) but to other elements like components, actors etc

[qwerty]

Let's ask the Pope (aka OMG). P. 97 starts a long chapter about Classification. It starts with this:

Classification is an important technique for organization. This clause specifies concepts relating to classification. The core concept is Classifier, an abstract metaclass whose concrete subclasses are used to classify different kinds of values. The other metaclasses in this clause represent the constituents of Classifiers, models of how Classifiers are instantiated using InstanceSpecifications, and various relationships between all of these concepts.

and the next paragraph "Classifiers" like this

A Classifier represents a classification of instances according to their Features. Classifiers are organized in hierarchies by Generalizations. RedefinableElements may be redefined in the context of Generalization hierarchies.

Now it's clear as dumpling stock (German proverb that might carry the idea). Take the specs and start reading from there.

q.

[Glassboy]

Now it's clear as dumpling stock (German proverb that might carry the idea). Take the specs and start reading from there.

Now that I'm working with a Dutch man I'm finding German proverbs way less cryptic :-)

[qwerty]

Dumplings (there are quite a number of different ones) are very tasty. But the stock is more like swill (and not clear at all). Funny enough the cited paragraphs resemble that swill in quite some way.

q.

[Paolo F Cantoni]

q, as usual, has "hit the nail on the head" - the definition is as clear as the stock he dumped.

ANY classification specialization is the selection of a subset of "instances" (of the base class) into a common "subClass" by virtue of the values of one or more features (in the UML sense - either attributes or operations).  So MaXym, if a car is a vehicle then you can describe it as "A vehicle such that...".  Similarly a BMW 318i is a car such that it is manufactured by BMW and designated model 318i.  I have not yet identified a specific vehicle.  Why?

Well, it relates to your example - the number plate.  While each car has a number plate what's more important is that each number plate (notionally) identifies, at most, one vehicle at a time.  Consequently, if (at least one) attribute will identify a specific car and therefore a specific (sub-class) BMW 318i, then it will end up selecting a sub-class of only one (maximum possible) instance and we, therefore, have a specific instance.  So BMW 318i with Plate number XYZZY specifies an instance.

It seems to me that it has to do with the query specification that defines the "Class" if, structurally, the query will only return (at most) one instance then we have an instance specification; otherwise, we have a class specification.

Paolo

[Glassboy]

Well, it relates to your example - the number plate.  While each car has a number plate what's more important is that each number plate (notionally) identifies, at most, one vehicle at a time.  Consequently, if (at least one) attribute will identify a specific car and therefore a specific (sub-class) BMW 318i, then it will end up selecting a sub-class of only one (maximum possible) instance and we, therefore, have a specific instance.  So BMW 318i with Plate number XYZZY specifies an instance.

Just to nitpick.  The number plate is produced by the jurisdiction's transport registry and identifies the specific instance of a vehicle registration.  A vehicle that is not yet registered will not have a number plate.  When taken delivery of, the car will have dealer plates until it is sold and registered.

Each specific instance of "car" will have a VIN as per

• ISO 3779 – Road Vehicles – VIN Content and Structure
  ISO 3780 – Road Vehicles – World Manufacturer Identifier (WMI) code.

mic drop

[RoyC]

Well, let's just take Paolo's example to describe an instance as being an object of a specific type with a unique reference, which in this case is a BMW 318i with a unique VIN.

But to nitpick along with Glassboy, it is quite possible to take your registration plates off your old car and transfer them (officially and physically) to your new car. So, two objects, one unique reference. AND you can take the old registration plates off your new second-hand car and put a different set of plates on. So, one object, two unique references.

[Glassboy]

Or you could deregister your car and put the number plates on your beer fridge.  Which would still be a fridge and not a car (but should have a unique serial number).

[MaXyM]

and aleo you can have a car which is not registered for public communication, ie racing car, but it´s still a car and can be instantiated into the car.

[Paolo F Cantoni]

and aleo you can have a car which is not registered for public communication, ie racing car, but it´s still a car and can be instantiated into the car.

Your collective points being?

I WAS careful to note that a number plate will identify (at least within the system) AT MOST one motor car.  So the plates on the fridge may or may not identify a car ("now").   

Having spent a few months modelling at the Department of Motor Transport (NSW), I DO know a little bit about how to model motor vehicles.

A class is an aggregation of instances (a set), an instance is a set member.  The set members are the ultimate leaves of the classification hierarchy we are dealing with. That is, you can't disaggregate an instance.  That instance can be either specific (where the identifying condition structurally will identify a specific item) or a placeholder for such.

As Uffe pointed out, early on, it is IMPORTANT (if not VITAL) to distinguish between "The Customer that has been identified as the person John Smith" and "The Person John Smith".  They are both instances, but one is an instance of Customer, the other an instance of Person.

Paolo

[qwerty]

FWIW: When defining a domain model, discussions about the single domain objects tend to stretch over weeks especially when discussing such "simple" things like Customer or Car. Everyone can throw in his opinion on how such an object should look like by pondering personal experience. This is done by an abstraction process going from instances (as everybody knows) to a common class (the business object we're after). I wouldn't expect this discussion here to become shorter as it is about describing the abstraction process behind the abstraction process (if that's clear?).

I'd simply say (to not get too philosophical): an "Instance" is something you can perceive with your senses. If you want to get philosophical you should look into the OMG specification above. You decide.

q.

P.S. Magritte's painting (and the discussion around concreteness of things) is originated from Plato's Allegory of the Cave. You might start there as well.

[sargasso]

an "Instance" is something you can perceive with your senses

Far, far, far be it for me to throw a (conceptual) "spanner" into the (conceptual) "machinery", but ....
a (conceptual) "instance", which I conceive that the (conceptual) "Paolo" may have been alluding to can also be a thing beyond our perception. Putting that another way, can an instance be imaginary?

YMMV, but personally, I certainly hope so. Because if not, then the (classifier) "set of imaginary numbers" could not exist. Therefore, the square root of -1 could not exist. Therefore a great deal of the mathematics of quantum physics could not exist. Thus it follows that a great deal of semiconductor technology could not etc etc. Etc, ad absudium, until this "thing" that I perceive that I am banging my fingers on cannot exist.  Which is a bit of a problem, because then, none of you exist. (Others have discussed this in detail.) Ahem, to get back on track..

"Why is a raven like a writing desk?" is a question posed by a mathematician of the 19th century who did a bit of work on set theory a wrote a certain book. Or at least I conceive that he was and did, for I have never met the fellow. His generally accepted identifying attribute was (and still is) "Lewis Carroll". He had other identifying attributes as well, but that would depend on the "classification scheme" that could be used. (You see where I am going here?) The one I will use in this instance discussion is (let's just accept, for the sake of sanity) "The set of all English writers, mathematicians, logicians, Anglican deacons, and photographers born in a parsonage at Daresbury, Cheshire in  January 1832 and resident at Christ Church College, Oxford in 1862". Hopefully then, one could construct a Carroll diagram where the cardinality of the set of instances in the "Yes" box is 1. However, that is not important.

What is important is that at that time "set theory" or the "mathematics of categorization" had just begun to be formalized (or at least in the so-called "western hemisphere" of this planet). Now, "a set" is unfortunately just a concept, you cannot pick up (touch) "a set", nor can you see, hear, smell or taste "a set". But it is a good thing that instances of "a set" exist, because if not then Dr Codd could not have invented relational theory and then...
(and don't even think about, let alone mention, "the set of all sets" at this point. It's been done.)

Which in my usual obtuse fashion, brings me back to the point.

Set theory is is the science of categorization. To keep this short, in a Venn diagram the rectangle is the universe of all physical and conceptual "things", the circles are classifiers which abstract a set into which one can put or not put (or partially put!) "things". (Deep breath) A class, as we use the term here, is a description of such an abstraction of a set. And an instance is one, and only one, of those "things".

All "things" exist, physical and conceptual, invented and not-yet invented. They are in Venn's rectangle. Out job is to decide whether they are also inside this or that circle or both or neither (or partially). To be successful, we must define the circles properly such that they adequately describe their membership.

So, qwerty, I agree with you entirely or at least 99%.  For sure, there are Cars and Customers and Cabbages and Kings. But there are also Accounts and Payments and Messages and Ratios and other kinds of things.

BTW, regarding ravens etc, just like the Hatter and Dodgson, I have no idea either.

b
(I think I might go and have a little lie down now.)

[qwerty]

Citing without context is, hmm - how to say this polite? I said "(to not get too philosophical)".

q.

[Glassboy]

Your collective points being?

In the interests of consistency - number plate isn't an attribute of a class called car.  It's an attribute of another class. :-)

[Paolo F Cantoni]

Your collective points being?

In the interests of consistency - number plate isn't an attribute of a class called car.  It's an attribute of another class. :-)

It can be a derived attribute of a car...  Using J.R. Abrial's⁽¹⁾ Access Functions we can define Car.NumberPlate as NumberOf(PlateAttachedTo(Car)).   The Access Function precisely defining the query required to return the Number Plate against a specific Car.

Paolo

⁽¹⁾My hero...