When is a Classifier

[Paolo F Cantoni]

I've been playing a lot with instance models recently.  In that process, I investigated the relationship between the instance and its classifier.  EA allows you to take a classifier (say a component) and (by means of its inconsistent EAUI) turn it into a component instance.  Elsewhere I have mentioned a number of inconsistencies in the way instances are handled by EA but this topic is about some thougthts that one of those inconsistencies triggered.

So, it turns out that if you try to assign a classifier using the <context menu>|Advanced>|Instance Classifier... [Ctrl+L] functionality, in the list of available classifiers will be found instances - such as the component instances above - (presumably because of a bug in the filtering process).

(expletive)! I thought another EA bug - which it is.  But then my mind went back nearly 20 years to a presentation I attended in Sydney, Australia on "Classless Objects".  The thesis of the presentation was that there weren't such things as classes, just "naked" objects that could be grouped at run time according to some selection criteria.  I let the presenter get to the end of his presentation and asked him if the selection process classified the objects into groups?  He agreed it did!  So I then asked him what a class was - if not a classification of objects?

So that got me wondering again...  What is a Classifier?  Here's what the UML 2.2 Superstructure (formal) Specification says (in part) on the matter:

[size=14]7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)[/size]
A classifier is a classification of instances, it describes a set of instances that have features in common.

Description
A classifier is a namespace whose members can include features. Classifier is an abstract metaclass.
A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to other classifiers. A classifier can specify a generalization hierarchy by referencing its general classifiers.
A classifier is a redefinable element, meaning that it is possible to redefine nested classifiers.
So, we see that the only real definition is a set of instances that have features in common.

We know that we can ascribe values to the features using the RunState.  Here's an instance of Bank Account with feature OwnerName=Paolo.  So far so good.

Suppose though, I want to show how this (particular) bank account goes through a cycle of states.  Is the set of Bank Account instances all with OwnerName=Paolo a set of instances having features in common?  I'd suggest yes!  So, does that make the original instance a classifier for this set?  Well that's the question...

What do others think?

Paolo

[Geert Bellekens]

Paolo,

I think in theory that could be correct. The Classifier would then become PaolosBankAccount, which could maybe have a generalization to BankAccount.

In practice that would be rather uncommon to model a Classifier for the bankaccount of a specific person, but there are other examples to be found where this would be a normal practice.
Say you have a shop that sells ICT stuff, there could be a general classifier Product and a more specific classifier HardWareProduct that is characterised by the fact that the attribute "productType" always has the value "Hardware".

Same pattern, but this time pretty acceptable for most of us.

Geert

PS. Happy Australia Day

[son-of-sargasso]

Anything with four legs is a dog!

NO.

So, we see that the only real definition is a set of instances that have features in common.

NO.

A classifier is a classification of instances, it describes a set of instances that have features in common.

Pertinent word is "describes".  Albeit, I can't really find a UML semantic for "describes", but... the moment you ascribe a classifier by the value of one of its' attributes, well, then, your back into instances again.

Second pertinent,  

Classifier is an abstract metaclass.

.  Ergo, ipso facto, and in terms of Terra Igcognito, notwithsitting the number of traditional celebrations I have had today (hic) .. again, you can't describe a dog (classifier) as all things called "Spot".

I think, or thought, or thunk.

As always, ymmv.

very cheers
bruce

p.s.  I just tried to create an instance of PaolosBankAccount with the method Transfer(amount:real, toaccount: BrucesBankAccount) and the first test case failed.  Please advise soonest.

[Geert Bellekens]

Ergo, ipso facto, and in terms of Terra Igcognito, notwithsitting the number of traditional celebrations I have had today (hic) .. again, you can't describe a dog (classifier) as all things called "Spot".
 

Indeed, you cannot describe a dog that way, but I don't see why you couldn't describe the classifier DogNamedSpot that way. (i.e. all dogs with the name "Spot")

Geert

[fwoolz]

SOS,

I believe that method has some OCL under the hood that says something like this:

pre: User.PIN = Paolos.PIN
pre: User.HasStolenPaolosBankCard = True

Fred

[Paolo F Cantoni]

Thanks everyone for your input so far - please feel free to contribute some more.

Before more formally responding (although in principle, at this point, I agree with Geert) I thought I'd do a bit more digging...

Just as I asked the question "When is a Classifier?"  it begs the question:  "When is an Instance?"

Until today, I thought that InstanceSpecification was the new UML2 name for an Instance.  Indeed, some searching on the Net  seems to confirm that: "An object instance may be called an instance specification or just an instance."  Elsewhere: "In UML models, instance specifications are elements that represent an instance in the modelled system"

However, reading the UML 2.2 Superstructure (formal) Specification:

[size=14]6.3.2 Semantic Levels and Naming[/size]
A large number of UML metaclasses can be arranged into 4 levels with metasemantic relationships among the metaclasses in the different levels that transcend different semantic categories (e.g., classifiers, events, behaviors). [size=18]...[/size] The following 4 levels are important:
Type level – Represents generic types of entities in models, such as classes, states, activities, events, etc. These are the most common constituents of models because models are primarily about making generic specifications.
Instance level – These are the things that models represent at runtime. [size=18]...[/size]
Value specifications – A realization of UML2, compared to UML, is that values can be specified at various levels of precision. The specification of a value is not necessarily an instance; it might be a large set of possible instances consistent with certain conditions. What appears in models is usually not instances (individual values) but specifications of values that may or may not be limited to a single value. In any case, models contain specifications of values, not values
themselves, which are runtime entities.
Individual appearances of a type within a context – These are roles within a generic, reusable context. When their context is instantiated, they are also bound to contained instances, but as model elements they are reusable structural parts of their context; they are not instances themselves. [size=18]...[/size]

We have established the following naming patterns:
Types : Instances : Values : Uses
Classifier, Class : Instance, Object : InstanceSpecification : Part, Role, Attribute,
XXXUse (e.g., CollaborationUse)
Event : Occurrence : OccurrenceSpecification : various (e.g., Trigger)
Behavior : Execution : ExecutionSpecification : various (e.g., ActivityNode, State),
XXXUse (e.g., InteractionUse)
(I've used: [size=18]...[/size] to remove some text to reduce the size)

Can anyone "unpack" the set of naming patterns above (particularly the second - was it just a typo and InstanceSpecification should have read ValueSpecification)?

Do you believe (or do you have a normative reference for) an InstanceSpecification is/is not an Instance?

Any help/thoughts appreciated...
Paolo

[Geert Bellekens]

Paolo,

In think the InstanceSpecification is the element to use when we are talking about instances or objects. (as commonly understood)
The quote from the UML superstructure my prove usefull, especially the part i've put in bold confirms this line of thinking.

7.3.22 InstanceSpecification (from Kernel)
An instance specification is a model element that represents an instance in a modeled system.
Generalizations
• “PackageableElement (from Kernel)” on page 109
Description
An instance specification specifies existence of an entity in a modeled system and completely or partially describes the
entity. The description may include:
• Classification of the entity by one or more classifiers of which the entity is an instance. If the only classifier specified is
abstract, then the instance specification only partially describes the entity.
• The kind of instance, based on its classifier or classifiers. For example, an instance specification whose classifier is a
class describes an object of that class, while an instance specification whose classifier is an association describes a link
of that association.
• Specification of values of structural features of the entity. Not all structural features of all classifiers of the instance
specification need be represented by slots, in which case the instance specification is a partial description.
• Specification of how to compute, derive, or construct the instance (optional).
InstanceSpecification is a concrete class.

at least that is what I think it means

Geert

[Paolo F Cantoni]

Geert.

I agree...

But then how do you interpret the second (or all) pattern above?

Paolo

[Geert Bellekens]

The second: (abstract classifier)
I think it means that if you create an InstancSpecification and you make it an instance of an abstract Classifier that you don't have a complete specification of the instance, since such an instance cannot exists (due to the abstract nature ).
For a complete specification you need to combine that "abstract" instance with an instance of a more specific concrete Classifier.

To use an example:
If I have an abstract class "Animal" then I'm allowed to create an instance of that class anAnimal:Animal but that instance can never be a complete specification of an animal.
It has to be combined with an instance of the concrete class "Dog" or "Cat". To get a complete speficiation.

I can't really think of a concrete (pun intended) case where that would be of use, but theoretically I can understand it.

Geert

[Paolo F Cantoni]

Hi Geert,

Before I reply more fully, can you explain why Animal is an abstract class and why Cat or Dog is a concrete class?

Suppose I have a class LifeForm which is a generalization of Animal, does that change anything?

What about HairlessCat, CollieDog.  Do they change anything?

One of the problems is that "abstract" is a funny (somewhat vague) term in English (at least).  I was discussing this with a work colleague today.

In manufacturing terms, "if a class has at least one abstract method then it is an abstract class".  However, in modelling terms, without specifying the methods of a class is there any way to determine a priori that a class is abstract or not?

This isn't a rhetorical question, it's always intrigued me...
Paolo

[Geert Bellekens]

hmm, need to think about that. Get back to you later

Geert

[Geert Bellekens]

Paolo,

Even in manufacturing terms it's not that simple, because you could perfectly have an abstract class without abstract operations.

(I used "operation" intentionally. I think "method" usually refers to the implementation of an operation; which is of course contradictory with the concept of an abstract operation)

Maybe we should turn the question around. What makes something not abstract or concrete? Is a classifier concrete when it completely describes the structure and behavior of a set of instances?

So in those terms abstract would mean that the specification of the structure and behavior of that set of instances is incomplete.

what do you think?

Geert

[Paolo F Cantoni]

Paolo,

Even in manufacturing terms it's not that simple, because you could perfectly have an abstract class without abstract operations.

(I used "operation" intentionally. I think "method" usually refers to the implementation of an operation; which is of course contradictory with the concept of an abstract operation)

Maybe we should turn the question around. What makes something not abstract or concrete? Is a classifier concrete when it completely describes the structure and behavior of a set of instances?

So in those terms abstract would mean that the specification of the structure and behavior of that set of instances is incomplete.

what do you think?

Geert

I take your point about method and operation -a slip of the mind on my part.

However, I'm not so sure about the other bit.

If I have a class with no operations, then I could assert it is abstract.  If I have a class with operations, none of which are abstract, then I can't assert it is abstract - since I can't apply the "duck" test...
I can only rely on the "a class with at least one abstract operation is an abstract class".

What do others think?

Paolo

[son-of-sargasso]

One of the problems here is that "abstract class" is not an adjective and a noun, its a "single noun", with a precise UML definition: "A class that cannot be directly instantiated".  On the other hand, a class that is abstract in terms of count(abstract operations) appears to be a different kind of duck.  

Going backwards up the thread:
Geert(4:33am)

What makes something not abstract or concrete? Is a classifier concrete when it completely describes the structure and behavior of a set of instances?

If the classifier is a class then UML defines them succinctly. As above, and for "concrete class" : "A class that can be directly instantiated."

Paolo(1:13am)

can you explain why Animal is an abstract class and why Cat or Dog is a concrete class?

I think that was just the way that Geert described them in his model.  

Geert(yetserday)

I think it means that if you create an InstancSpecification and you make it an instance of an abstract Classifier that you don't have a complete specification of the instance, since such an instance cannot exists (due to the abstract nature ).
For a complete specification you need to combine that "abstract" instance with an instance of a more specific concrete Classifier.

My reading is that if you make it a "realization" of only an abstract classifier then you have, by UML definition, a partial description of the real instance.

My reading:
Level one of the "naming conventions" talks about the things that exist at runtime.  Level2 and below talk about things that exist in UML models, i.e. things that all descend back to Kernel:element.

Ergo, an instance which is a member of the runtime "Instances" set is the thing that exists in a computers memory that fully describes whatever that instance represents, e.g.

Code: [Select]

DIM mydog as Animal
DIM yourdog as Dog
mydog and yourdog are instances.
Also, the spec seems to imply that instances are values, in other words they fully define (to the application) what mydog and yourdog are.

An InstanceSpecification is an element in a UML model that fully or partially defines models an Instance.  These elements can also be facets of the model (i.e. dependent on the viewpoint of the model compartment) (I cant remember where I read that bit, its in the spec somewhere.)

An Object is an InstanceSpecification of a Class. By extrapolation, a Class is an InstanceSpecification of Classifier (N.B. NOT a classifier).

Also,

specification : ValueSpecification [0..1]A specification of how to compute, derive, or construct the instance. Subsets Element : : ownedElement.

(My bold)

Finally, ..... :-/

Given, that an Object is an InstanceSpecification and it can be a partial description, then...

Here's an instance of Bank Account with feature OwnerName=Paolo.

Intuitively, this is a partial description, as we all "know" that there is more to "BankAccount" than just a OwnerName.  Furthermore, the description does not qualify what a "Paolo" is.  But, we all assume that its a classifier called string with a value of "Paolo".  So for the purposes of this "model" in this thread, we can  live with the assumption that for the purposes of this discussion, that is an adequate description of a "PaolosBankAccount" element.

Getting back to mydog: :Animal(name="Spot") and yourdog: : Dog(numlegs=3;name="Spot") where Dog descends from Animal, what happens when we coerce yourdog to an instance of Animal. Is Animal(yourdog) == mydog? Isn't UML wonderful?

bruce

{edit - mod to remove stupid automatic smileys means that colon;colon apears as " : : "}

[fwoolz]

I would start by offering that a class is abstract if it has no instances. A drawing of a widget is an abstraction of a widget, and it has no concrete representation until the first widget is made. All classifiers, then, are abstract in this sense until instantiated. But it doesn't follow that their UML counterparts should then be marked as abstract.

Sticking with the drawing metaphor, you might have a drawing of a safety decal that shows a black border around a white background, with a red oval in the middle with the text, "WARNING MESSAGE HERE" in white. You never expect to produce anything from this drawing directly; it can serve, however, as a template for real decals like "DANGER - DOG NAMED SPOT" or "WARNING - DUCKS QUACKING TYPING"   or whatever. The first drawing is an abstract classifier - it has no concrete instances AND is never expected to have any. Yet it defines some concrete representations in instances of drawings derived from it; it did, after all, define the background, the border, and the red oval with white text. The border, background, oval, and text color could be seen as concrete "operations," while the "WARNING MESSAGE HERE" operation is abstract. So the original drawing IS an abstract classifier - it has at least one abstract "operation" which means it can never be instantiated (manufactured); only derived drawings which provide concrete implementations of the abstract "operation(s)" can be "produced." So classes/classifiers would be marked "abstract" if they have at least one abstract operation. I might extend this to properties as well, and not just the ones that are methods with sugar on top but also to attributes that have an abstract type (classifier).

So Paolo's take seems to cover matters pretty well.

PS: I might add that one could posit that the only PURE abstract classifier is <NULL>, as in the empty set is a subset of all sets. Even if I declare an interface with 2 methods, like so:

Code: [Select]

interface Pet
{
    Sound bark(double volume);
    Sound quack(double volume);
}I've already limited derived classifiers to something less than the Universal set (for instance, pet rocks wouldn't do because they don't implement either method).