Wrong port properties selected

[qwerty]

I have a very strange issue for one client (V13.5). Imagine a class with a port and a instance of both. Now when this client opens the port instance's properties floating window it does load its parent's properties instead! I have no idea what this could be. I forgot looking at the docked window but they work with the floating properties anyway.

Yes, I turned the machine off an on, disabled all add-ins, ran the consistency check and prayed to God already. None did help. And re-installing is currently not possible due to admin-mania and Corona-hysteria.

Anyone had a similar issue?

q.

P.S. This also happens to another client. My installation does not show that behavior, though.

[Eve]

I just need to clarify terms.

Class with port is fine.

Instance of both. I can imagine two different interpretations of this, and they should behave differently.

If your class instance is an EA Object/UML InstanceSpecification, the instance of the port means that is actually a slot.

If your class instance is actually a Part (which is similar notation to an Object), the instance of the port is what EA calls a reuse. From a UML perspective they are the same element.

Normally I would assume that the "parent" of the port instance would mean the "owner". But given what I know it could be that you mean to defining Port instead.

Now, I don't remember exactly what the behavior of 13.5 was. It's ancient history as far as I'm concerned and I can't keep those details in my head. The current version of EA will allow you to edit a Slot. It is a unique object, with something akin to a classifier relationship to the original. I do remember a time where EA would confuse that with a re-use and not allow it to be edited though.

As far as the re-use goes. EA used to just prevent you from editing the element, while any time it was loaded it would just load the original instead. Current versions of EA allow directly editing the original when the reuse is selected.

So, it's possible that your users have created a Part, while you have created an Object.

[qwerty]

Hmm. Lots of new stuff. I did not dig into that area of UML and honestly the term Slot was new to me (I quickly skimmed the spec but need more time).

Actually to what I seem to understand this could well be an issue with EA. Just let me tell the steps done in V13.5:

- Create a class with port
- Ctrl drag the class onto a diagram and create an instance
- Upon creation you get presented the Structural Elements dialog where you tick the port so it appears on the diagram

Now (if I got that right) I will see an Object with Slots. Now when my client opens the Slot properties he's presented the Port's properties instead. When I take this model and do the same on my machine it opens the Slot's properties (as expected).

I can probably assume that this might be an EA bug in V13.5 and not some setting which makes EA behave differently?

---

Just a little background: my customer, being a large automotive company, is deploying 13.5 at most of their work stations. V14 is approved but only randomly deployed. V15 is being investigated. Now, I do know most of the icebergs in the V13.5 sea and know how to navigate around - except for example those Slots. I also know some big ones in the V14 sea and would like to just avoid it. For V15 I only have the Daily Shipwreck as a source and *really* want to avoid that. But if you (directly or indirectly) tell me that this is an issue with V13.5 we have to set sail for the unknown.

q.

[qwerty]

I kept on playing and now made a step towards the issue. When creating a Part you can choose Show inherited. Now if you do that, EA creates a new Port (actually being a Slot, right?) - so it looks.

When you open the docked properties window and alternatingly click the Port and the Slot (EA isn't using the metatype btw.) you see - no change. The GUID shown in the window is shown to be the same. What? Now, when you issue a Copy GUID you get two different ones??? Who's trying to fool me?

But wait! What happens now? I open the floating properties of the Slot, change its name and (why now???) the name of the Port is changed as well? What?

I have to try that with V15. Just to see whether it's fixed there. But first I have to have a beer, or a coffee, or both.

q.

[qwerty]

Ah, well. Different version, same bug. Ports and Slot are still related by NAME (like so often in EA). You have no idea which slot is related to which port. If you rename them (having equal names) it's arbitrary which corresponding part will be renamed. And in no way you can actually see that a slot is derived from a port.

q.

[qwerty]

If your class instance is actually a Part (which is similar notation to an Object), the instance of the port is what EA calls a reuse. From a UML perspective they are the same element.

If a slot in a part is the same element as the port from its classifying class, then why does EA show two different tree elements? And still pretending they have the same guid (looking at the properties window) but actually are not (by using copy GUID)? What should that be called? Split personality? Dr. Jekyll and Mr. Hyde?

q.

[qwerty]

I did a bit more reading. The term Slot seems to mean the "variable = value" entries in an object.

A Slot specifies that an instance modeled by an InstanceSpecification has a value or values for a specific StructuralFeature

A Slot designates that an entity modeled by an InstanceSpecification has a value or values for a specific StructuralFeature.

I found the use of slot in conjunction with ports only in one book (and it does not look like it means the UML term Slot right there). So where does your definition come from? Or did I just misunderstand you?

q.

P.S. And why is it that class instances (objects) can no longer have the ports of their classifiers as structural elements in V15? The context menu is gone.

[Eve]

Too many questions for me to keep track of right now.

Yes, slots are one of the more obscure parts of UML in my mind. I've seen them used more with SysML and related UML extensions. They are the containers for actual values on an instance. Not sure how to better explain what's going on with that. When you model a type, you define the properties that it contains. When you create an instance of that type, those properties become containers for actual values. That's what a slot is. Ports notation for slots is just because Ports are a specialized kind of Property, and any property would be a slot on the instance. It's most natural to keep the existing notation.

13.5 (and even 14) may not show it, but the full text notation for a slot, as displayed by the version I'm using, is: <slot-name> / <defining-feature-name> : <type-name>

Oh, and EA makes the link from slot to property in PDATA/MiscData. The link is not by name.

As for re-use elements, they are used when a property is displaying the properties of its type. They are the same object as far as UML is concerned, but they kind of have a different parent, they need different relationships at times, more than one can be shown on a diagram at the same time. Having a separate t_object record for them is just a way to make all of those special behaviors work. Where possible EA does its best to allow you to see them as the same element.

I hope that answers most, if not all, of your questions.

[qwerty]

More or less I get it. Obscure is the right word. Using a Part is, so to say, a complex attribute. As such the ports of the classifier are doppelganger of the classifier. I can see that people (coming from SysML) would like to use these. For me (coming from software engineering/compiler construction) it sort of gives me the creeps. Attributes are references. But what would be an instance in a class? No wonder the realization is creepy too. In the browser tree you see two ports which as you said should be identical. EA pretends that by showing them with the same guid. And it mimics that be shadowing changes. This is done for the name, stereotype etc. But not for all properties (can't recall which while playing around). And for the tagged values you see the "From <classifier>" as inherited. That's the Dr. Jekyll part. When you copy the guid from the context menu you see Mr. Hyde (in the form of the different guids). So far that's like it is.

Now, if you say that both are identical then how can it be that you have individual connectors? I can't understand that.

q.