Initial values hijacked in instances / specializations

[Uffe]

Hello,


This is in 13.5, but there's no mention of any relevant changes in the history for 14.

Let's I create a class with an attribute with an initial value.

Let's then say I create both an instance of that class, and another class which is a specialization of the first class.
I switch on presentation of inherited attributes for both the instance and the specialized class.

If I now override the attribute initializer in my specialized class, that overridden value is shown in the local attribute compartment of that class. Good.
But the same change is shown in the inherited attribute compartment. In other words, it now looks like the attribute in the general class has the same initial value as it does in the specialized class -- which it doesn't.

This isn't great, but semantically I suppose you could overlook it: there is only one initial value for any given attribute (since an instance cannot logically be initialized twice), so the presentation of the parent's initializer is more of a convenience. It'd be nice if it was right, but it's not crucial.

But now consider the same situation with an instance with a run state, which exhibits the same behaviour.

In my instance it now looks like the initial value is what I've put into the run state. This is definitely wrong. The initial value is a property of the classifier -- it cannot change with the run state, which is a property of the instance.

Or is there some obscure Jehova's Witness-style mangling of the UML standard that allows for this behaviour?


/Uffe

[Paolo F Cantoni]

Hi Uffe,

as you probably know, I've been arguing (with myself) about what does "instance" actually mean?.  Your recent posts (this and the one on Artifacts)  has got me thinking again and I may have made some progress as a result.

As you'd expect, any insight I might have has to do with the semantics involved.  Also, it involves "first principles".

As one should expect, the notion of a classifier is a mechanism to describe a number of instances having common values for one or more of the classifier's features.

In UML, a Class is a classifier from which may be generated transient run-time instances called Objects - for the purposes of running a software system.  The key thing for me here is that the Objects don't have a lifetime of their own, they are merely "alive" for the time the instance of the software.

If we are modelling the real world, however, instances have their own lifetimes (it could be argued - and I do! - that they are not tied to the lifetimes of their - potentially multiple - classifiers).  Consequently, I now believe that one should NOT use Objects for modelling instances (other than the transient instances of software systems).  Indeed one can see this in the concept of the Object's RunState - it is about the state while it is running (that is, alive, in the software system)!  This is the insight, I  believe I've just had.  I should stop using the term Object for anything other than the transient instances within the software system.

That leaves us with the notion of specific versus placeholder instances (What is an "Instance"? mentions specific vs generic, but I believe placeholder is more semantically correct) contrasted with the notion of a classifier.

I'm now of the view that, for example, modelling Business Actors (in the ArchiMate sense) each item we create of metatype Actor is either a specific or a placeholder instance (but ALWAYS an instance).  Thus we can have "John Smith" and "ABC Corporation" as specific instances and "a customer" and "a supplier" as placeholder instances (note the use of the indefinite article) where we can define a restrictive query to validate whether a specific actor instance can be substituted, as required.  "a customer" is defined as "a business entity" that has ordered (or has the ability to order) "a good and/or service" from us.  "Actor" is the metatype (Classifier) which defines which features all Actor instances can have.

So, it seems to me that EA is actually working (relatively) correctly.  Since, by the above, you should be using Restrictive (Specialized) Artifacts to create placeholder and thence specific instances.

Does that help?

Paolo