Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Ian Mitchell on February 20, 2016, 02:04:07 am
-
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?
-
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
-
What Uffe said ;D
Geert
-
Not to forget the recent Life Line / Object discussion.
q.
-
...
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.
-
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.
-
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.
-
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 (http://sparxsystems.com/forums/smf/index.php/topic,30340.0.html)
-
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.
-
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?
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
That would excite me if it also had a red nose that lit up.
-
You can easily show that with a shape script.
q.
-
[Homily]
Everything should be able to have everything.
Separately you can create modifiable rule sets that implement a standard.
For example, in our case, we decided to remove the Actor - ActorInformation spurious dichotomy and just allow the information aspects of actors to be expressed as Features of the Actor.
Users should be given the most potential freedom, but initially restrained by the rules; until they are able - by their own want and ability - to modify the rules to suit their evolving needs and understanding.
[/Homily]
Paolo
-
You can easily show that with a shape script.
I wonder how that would go as a feature request. It would make the release notes more fun.
-
So this is the list of element types which create instances which have the same object_type as their classifier:
- Component - and, i think, MDGs which create stereotypes of Component
- Artifact
- Requirements Checklist
- Matrix specification
- Report specification
- Activity
- Collaboration (not the new V14 collaboration thing - i think)
- Deployment Specification
- Device
- Encrypted Document
- Execution environment
- Review (the v13/14 idea)
- Node
Please note also:
- this is just derived from experimentation, so Sparx might change it if they feel like it
- these are just the types I can find - there may be more
- its seems likely that stereotypes of these types which are created by MDGs will also create 'typed' instances, but I've only looked at a few, and lots of MDGs just stereotype 'Class', so they will produce object_type="Object" anyway.
- I have no idea what instances of some of these mean in a model!
- all other seem to create instances with object_type="Object"
@querty - maybe this could go into the next 'Inside EA'?
Can I have my life back now please ?
-
I'll put that on my todo list :-)
q.
-
Wow, you... actually sat down and did that.
That is laudable, or possibly certifiable. I get them confused. Either way, you deserve a long weekend.
On artifacts, I remember this discussion was up at some point and someone from Sparx said that there's a bug, which will be fixed, in how EA handles instantiation of artifacts, and that's why instances of artifacts appear to be both classifiers and instances.
I had a trawl through my mailbox but I couldn't find it. Possibly it's in a thread here on the forum.
/Uffe
-
Wow, you... actually sat down and did that.
That is laudable, or possibly certifiable. I get them confused. Either way, you deserve a long weekend.
On artifacts, I remember this discussion was up at some point and someone from Sparx said that there's a bug, which will be fixed, in how EA handles instantiation of artifacts, and that's why instances of artifacts appear to be both classifiers and instances.
I had a trawl through my mailbox but I couldn't find it. Possibly it's in a thread here on the forum.
/Uffe
Remember, Uffe, the only certifiably sane people are those who have been certifiably insane in the first place... :D
Paolo
-
Wow, you... actually sat down and did that.
That is laudable, or possibly certifiable. I get them confused. Either way, you deserve a long weekend.
On artifacts, I remember this discussion was up at some point and someone from Sparx said that there's a bug, which will be fixed, in how EA handles instantiation of artifacts, and that's why instances of artifacts appear to be both classifiers and instances.
I had a trawl through my mailbox but I couldn't find it. Possibly it's in a thread here on the forum.
/Uffe
Hi Uffe
Madness is not alone - found myself doing this last year (or was it 2016, also have memory loss). It was a necessary exercise in determining what metaclasses to base a new profile on. So there was method in the madness. I anticipate Ian is also following a similar train of thought ...........
Namaste
YM
-
It finally made it with an (almost) complete list. Book update will be released during this week.
q.