When is an instance not an Object?

[Ian Mitchell]

When we create EA Instances of EA things (Class, Use case, Actor etc) then EA creates a new entry in t_object, with Object_Type = "Object", and an instance classifier which points to the relevant 'thing'.
Perfect.
But when I create an instance of a 'DeploymentSpecification', I get the correct instance classifier pointer, but the instance 'thing' has an object_type="DeploymentSpecification", not "Object".
Are there other EA meta-types which create instances which aren't "Objects"?
Seems like the only way to distinguish between an instance and a 'thing' is the presence of the instance classifier, but that doesn't seem quite right....
If this a bug?
Or a feature?

[Uffe]

Hi Ian,


Short answer: sometimes.

When you create a stereotype in a profile, one of the things you can specify is the instance type, ie what type of element EA should pick when creating an instance of an element with your stereotype. You can also set the metatype for a stereotype, so if you define a stereotype which extends Object, you can cause it to appear to be something other than an Object in the GUI.

But what you've got right there is a bit of a rum one.

If you right-click an instance type element (like Object) and check under Advanced, you'll find the Instance Classifier menu item. This allows you to select which classifier the instance should refer to. That menu item is absent from classifier types, like Class.

Instance and classifier types also offer different options when dropped onto a diagram from the project browser. With a Class, you can select to paste as Link or paste as Instance (creating an Object), but with an Object you don't get the question: objects can't in turn be instantiated.

However, a deployment specification seems to be a bit of both. You can create a new deployment spec and specify a classifier for it, and you can drag it onto a diagram and create an instance from it. This is weird. Artifacts behave the same way (and I believe a deployment spec is in fact an extension of an Artifact).

A few simple tests show that Use Cases beget Use Cases, Nodes beget Nodes, but Activities beget Actions.

So there are several other classifier types which do not result in Objects. And the distinction between classifiers and instances is not clear-cut. In EA, at least -- not sure what the standard says.


HTH,


/Uffe

[Geert Bellekens]

What Uffe said

Geert

[qwerty]

Not to forget the recent Life Line / Object discussion.

q.

[Evgeny Florov]

...
However, a deployment specification seems to be a bit of both. You can create a new deployment spec and specify a classifier for it, and you can drag it onto a diagram and create an instance from it. This is weird. Artifacts behave the same way (and I believe a deployment spec is in fact an extension of an Artifact).
...
So there are several other classifier types which do not result in Objects. And the distinction between classifiers and instances is not clear-cut. In EA, at least -- not sure what the standard says.
...
/Uffe

All facts aren't so difficult.

1. Marketing of Sparx declares: "Ultimate Modeling Power / Precise and effective / Based on UML 2.5 - plus" ("http://sparxsystems.com/products/ea/index.html")

2. We take the UML 2.5 specification - "http://www.omg.org/spec/UML/2.5/PDF"

3. What is DeploymentSpecification? We look:

19.5.5 DeploymentSpecification [Class]
A deployment specification specifies a set of properties that determine execution parameters of a component artifact that
is deployed on a node. A deployment specification can be aimed at a specific type of container. An artifact that reifies or
implements deployment specification properties is a deployment descriptor.
  19.5.5.3 Generalizations -> Artifact

3. What is Artifact? We look:

19.5.1 Artifact [Class]
An artifact is the specification of a physical piece of information that is used or produced by a software development
process, or by deployment and operation of a system. Examples of artifacts include model files, source files, scripts, and
binary executable files, a table in a database system, a development deliverable, or a word-processing document, a mail
message. An artifact is the source of a deployment to a node.
  19.5.1.3 Generalizations -> Classifier, DeployedArtifact

It turns out that DeploymentSpecification is Classifier!
It is intuitively clear that "instances" of a type of "Classifier" can be formed.

4. What is the "instance"? We look:

9.8 Instances
9.8.1 Summary
InstanceSpecifications represent instances of Classifiers in a modeled system. They are often used to model example configurations of instances. They may be partial or complete representations of the instances that they correspond to.
9.8.3 Semantics
 ...
 The InstanceSpecification may represent:
 ...
   * The kind of instance, based on its classifiers. For example, an InstanceSpecification whose classifier is a Class describes an instance of that Class, while an InstanceSpecification whose classifier is an Association describes a link of that Association. If no classifiers are given, then the InstanceSpecification does not constrain the kind of instance represented. If classifiers of different kinds are given, then the semantics are not defined.
...

Interestingly that the concept "Object" as a formal element of the UML specification isn't applied (I didn't find).
It turns out that the Instance of DeploymentSpecification is on all signs there has to be either a Instance, or some specialization of a Instance of Classifier.

Now it isn't understood that such DeploymentSpecification Instance in EA at all. Definition of "Run states" that is logical is available to it. But how to understand from model of data of EA that this element is a Instance - not clearly.

[qwerty]

Interestingly that the concept "Object" as a formal element of the UML specification isn't applied (I didn't find).

You need to look into older UML specs. 1.5 states

3.39 Object
3.39.1 Semantics
An object represents a particular instance of a class. It has identity and attribute values. A similar notation also represents a role within a collaboration because roles have instance-like characteristics.

Another heritage.

q.

[Evgeny Florov]

You need to look into older UML specs. 1.5 states

3.39 Object
3.39.1 Semantics
An object represents a particular instance of a class. It has identity and attribute values. A similar notation also represents a role within a collaboration because roles have instance-like characteristics.

Another heritage.

q.

I understand. Also I remember that "Object" - was. But I wrote that:

All facts aren't so difficult.
1. Marketing of Sparx declares: "Ultimate Modeling Power / Precise and effective / Based on UML 2.5 - plus" ("http://sparxsystems.com/products/ea/index.html")

More in details it is described so:

Build upon UML 2.5
Enterprise Architect’s foundations are built upon the UML 2 specification - but it doesn’t stop there!
...

Therefore I decided to look actual 2.5.

[qwerty]

Means: Sparx is lying upon its advertisements. More polite: someone should report a bug.

q.

P.S. See also here: http://sparxsystems.com/forums/smf/index.php/topic,30340.0.html

[Eve]

How the information is represented internally to EA isn't about for UML conformance. The questions there are: Can you create it? Does the appearance match the spec? Does it generate the correct XMI? Does it import from XMI?

UML says that  the default rendering of an InstanceSpecification is the same as the base classifier type, but with an underlined name. Yes, EA does represent an instance of most non rectangular types as the type plus a classifier. It's mostly legacy reasons why classes have object instead.

[Evgeny Florov]

How the information is represented internally to EA isn't about for UML conformance. The questions there are: Can you create it? Does the appearance match the spec? Does it generate the correct XMI? Does it import from XMI?

UML says that  the default rendering of an InstanceSpecification is the same as the base classifier type, but with an underlined name. Yes, EA does represent an instance of most non rectangular types as the type plus a classifier. It's mostly legacy reasons why classes have object instead.

Thanks.
Prompt please as on model of data of EA it is possible to understand unambiguously:
1. whether is the element - Classifier?
2. whether is the element - Instance?

[Ian Mitchell]

Whilst I'm obviously fascinated by the discussion on how UML-compliant EA is (actually, that's a lie - I don't care at all), my question is still un-answered, despite Uffe's wonderful and helpful post - ( "this is weird" 
Simply re-stated, hoping Spaxians will answer:

• which of the built-in EA element types create instances which have object_type= 'Object',
• which create instances which have the same object_type as their Instance Classifier?

There must be some code somewhere in EA which makes this happen, and I'd just like to know what it does.

[Eve]

Sorry, as much as I would like to help you with this, I'm not sure if anyone here can help you.

If you need a list of the types and the way their instance is represented in the database I recommend working it out by experimentation.

[Paolo F Cantoni]

Interesting...

I've come to the view that "Object" is a the name of the specific instance of a Class.  That is, Object==Instance_Of(Class). Other metatypes have instances of the same type E.g. ActorInstance==Instance_Of(Actor).

The problem may come about because Sparx EA has conflated the concept of Instance_Of and the t_object type="Object".  In other words, each element needs to have a flag indicating whether it is a classifier or an instance.  If it is an instance it can allow the reference (or at least identification) of its classifier.  (This is similar to the conflation of directionality and navigability for Association-like relationships - which can create a different set of problems)

My surmise, Michael, is that because of this conflation, over the years, different developers working at different times have taken different views on what can/should happen - EAUI.

So as Simon says, there's no option but to experiment and see what pops out.  If you decide to experiment, can you document what you find?

Unfortunately, some functionality in Sparx EA seems hard coded to the t_object type="Object" - so even creating a more consistent MDG is fraught with problems.

Paolo

[Ian Mitchell]

OK, so I followed Sparx' advice, and went though about 100 or so kinds of 'thing', and so far, I don't understand the pattern. Maybe it's a UML thing...
For example:
- An Interface can have attributes, but a Requirement can't
- A use case can have operations, but a Feature can't
- A (GUI) Screen can't have attributes, but an Activity can.
I'd be slightly interested if anyone has a common-sense rationale why this is true.
As I have eaDocX customers asking to print operation/attributes on all kinds of strange and wonderful element types, I've decided to let anything have the potential to print them, even if today EA doesn't allow it. Better that way than not allowing stuff which has already been modelled.
Apologies in advance to eaDocX customers, but there's only so much time I have to peer through the curtain that is the Sparx forum, and into the mind of The Wizard from Oz.

[qwerty]

Actors can't have operations. But if you create a class with operations and change it to be an actor it keeps the operations. Just to continue you list of strangenesses.

q.