object prototypes

[eberline]

Given instances of the same type, in which one is a prototype that only provides default attribute values for the others which then may override some of those defaults, how should that sort of relationship between instances be modeled?

(The context is large-scale game development, in which level designers and other non-programmers use the prototyping architecture to specialize game objects without creating subclasses and recompiling.)

Thanks for any tips. A custom stereotype on a dependency is the best I could come up with.

Cheers,

[Paolo F Cantoni]

Hi, eberline,

One could consider what you are doing as a form of specialization.  In our Modelling technology we have (effectively) 3 forms of specialization:
(classical) inheritance (IS_A_TYPE_OF)
restriction (IS_WHERE)
(generic) specialization (Don't know which of the above it is yet)

We, therefore, use three forms of stereotyped Generalization relationships to indicate this.

HTH,
Paolo

[eberline]

Thanks, Paolo, I really like that better already.
I'm going to work with that approach and see how it feels.

Cheers,

[Paolo F Cantoni]

Thanks, Paolo, I really like that better already.
I'm going to work with that approach and see how it feels.

Cheers,

Glad you like it!  It's worked for us.  If you can determine why the class is a specialization, you can relate it to the reason "Class" with a stereotyped dependency:
Discriminated by (for inheritance)
Restricted by (for restriction)
Specialized by (for specialization)

Thus a "Delivered Order" is a restriction on "Order" such that it is restricted by "Order Status - Completed".

HTH,
Paolo

[Richard Freggi]

Can objects be parents of a generalization association in UML?  After all they are just instances.

[Paolo F Cantoni]

Can objects be parents of a generalization association in UML?  After all, they are just instances.

Hi Richard,

These instances are NOT objects.  Objects are run-time instances of a specifying Class.  These instances have lifetimes outside the run-time.

This is one of the traps I fell into for almost a decade.  I alluded to it in eberline's other recent post.

HTH,
Paolo

[eberline]

These instances are NOT objects.  Objects are run-time instances of a specifying Class.

It's common among game engines that runtime supports design activities. A title is developed with the engine running "editor mode", and then played with a constrained & optimized build running "game mode". The same prototype instances are deserialized and then cloned, both in editor mode and game mode.

But...

That a new game object is instantiated by cloning its prototype, rather than by invoking a conventional constructor, is an implementation detail. So modeling these prototypes as classifiers related by «prototype» generalizations does seem more useful than as instances related by e.g. «prototype» dependencies. (For this model view's intent/audience.)

These instances have lifetimes outside the run-time.

(Wouldn't that would be true of any persistent object, e.g. in an object-relational database?)

Cheers,

[Paolo F Cantoni]

These instances are NOT objects.  Objects are run-time instances of a specifying Class.

It's common among game engines that runtime supports design activities. A title is developed with the engine running "editor mode", and then played with a constrained & optimized build running "game mode". The same prototype instances are deserialized and then cloned, both in editor mode and game mode.

But...

That a new game object is instantiated by cloning its prototype, rather than by invoking a conventional constructor, is an implementation detail. So modelling these prototypes as classifiers related by «prototype» generalizations does seem more useful than as instances related by e.g. «prototype» dependencies. (For this model view's intent/audience.)

These instances have lifetimes outside the run-time.

(Wouldn't that would be true of any persistent object, e.g. in an object-relational database?)

Cheers,

Yes, eberline,

I was speaking in the context of Sparx/UML Objects.  the t-object table has a column RunState which is only invoked/manifest when the object_type is "Object".  Other properties are also not manifest unless the object_type is "Object".

So, we came to the conclusion that in Sparx EA "Object" meant run-time object only.

Investigating the relationship between the various things we're trying to model with ArchiMate-like technology, we decided that we were basically dealing with two types of instances - specific instances (eberline, Paolo) and placeholder instances ((a) Developer, (an) Architect).

We came to the view that the concept of Class (Classifier) should be reserved for those types of items which define the structural and behavioural specification of the instances/run-time objects.  Thus, in our view, ArchiMate Actor is a Classifier, ALL Actors are instances.

The process of cloning is NOT one of classifier->run-time object, but not_classifier (instance?)->run-time object.  So a different relationship is required (you could use "isEnlivened" - given life - for this purpose).  The point is that the design mode item is an instance of the class of Actors, but in the game mode, it is give "live" and run-time specific properties which may vary from those "snapshotted" into the design mode instance. While they are both Theseus' ship, they aren't the same ship.

HTH,
Paolo

[Richard Freggi]

Can objects be parents of a generalization association in UML?  After all, they are just instances.

Hi Richard,

These instances are NOT objects.  Objects are run-time instances of a specifying Class.  These instances have lifetimes outside the run-time.

This is one of the traps I fell into for almost a decade.  I alluded to it in eberline's other recent post.

HTH,
Paolo

OK  since these instances are not objects, as long as we don't call them objects all good then.... I guess an object prototype is a class then?

[qwerty]

Since classes are instantiated and instances are synonyms for object, the answer is probably yes.

q.