Reference Association Bug? Workaround?

[Miguel]

Hi everyone,

It seems that there is a bug in EA 15.2 regarding the handling of Reference Associations in SysML.  I want to get your take on this and see if anyone has a good workaround.

In SysML, it's really hard to find a usable built-in distinction between Aggregation and Reference Association.  My understanding is that Aggregation is just a special type of Reference Association that allows for a custom stereotype.

However, EA doesn't handle these the same way.  Specifically, if I create an aggregation, the owning block gets a "reference" to the other object, but not so with Reference Association.  See below:



Note that Foo has a reference property to aBar but not one to aBaz.  In the model browser, it looks like this:



I'm pretty sure that this is wrong, and unfortunately, what this means is that I can't use "properties" of a Reference Association the way I can for an Aggregation.  For example, since it's not a property, working with IBDs is an issue.

Here it is in Cameo, for comparison:







One of the many fallouts is regarding the IBD for Foo, as I mentioned above.  Here's the IBD in EA:



Note, above... there just is no aBaz property for me to drag onto the IBD.

Cameo:



Bottom line, to me, it's a bug in EA that the block on the other end of a Reference Association is not itself a Reference Property in EA.  Your thoughts?  Anyone have a workaround?

[Miguel]

Hi All,

I was able to figure out a work-around for this, and want to put it on here for others. 

The problem listed in this thread is for EA15.2, as I said above.

In order to have a Reference Association that is represented as a reference property on the 'owning' block, I was able to first create an Aggregation, which does create the reference property, and then right-click->Advanced->Changed Type..., and select Association.  This changes to the type to what I wanted, but retains the reference property that was created when I created the Aggregation.  It's an annoying two-step process, and I hope this is resolved in a future version, but at least I can do what I needed in this way.

One thing to be aware of, though is that the navigability after the change type may not be what you expect.  I found that changing the navigability (on Properties) for the aggregation before changing its type worked best.