Aggregation Direction Flipping (Yes, I have read the threads ;))

[ejafman]

Hi all,

Read several threads about this, yet the workarounds aren't working.

I have actually hardcoded the following to test.
oSourceEnd is connector's Client End
oTargetEnd is connector's Supplier End
oConnector is the connector itself

Code: [Select]

  oConnector.Direction = "Source -> Destination"
  oSourceEnd.Navigable = "Navigable"
  oTargetEnd.Navigable = "Unspecified"
  oConnector.Update

Looks as if the "IsNavigable" boolean no longer exists, so I can't hardcode that.

Can't get the direction to = "Source -> Destination", even though the actual object in debug says it is.

Ideas anyone? Must be doing "something" wrong? I am clueless.

Thanks...Eric

[Geert Bellekens]

Eric, if you give a bit more information we would probably help you.

Make sure to include

- a complete enough code sample that can be used to replicate the issue
- the "start" situation
- what you are trying to achieve
- the current end result

You are saying things "aren't working" but that is not very helpful as a description of the problem.

Geert

[ejafman]

Understood...

I have cut down the code to the lowest common denominator.
When I set the EA objects, before the changes:
oConnector.Direction = "Source -> Destination"
oSourceEnd.Cardinality = "0..*"
oTargetEnd.Cardinality = "0..1"
oSourceEnd.Navigable = "Navigable"
oTargetEnd.Navigable = "Unspecified"

After running this (please know that the GUID I have selected is an "Aggregation"):

Code: [Select]

  Set oConnector = eaRepo.GetConnectorByGuid("{43839C7A-F120-43d1-8B85-328F89BA9AE6}")
  Set oSourceEnd = oConnector.ClientEnd
  Set oTargetEnd = oConnector.SupplierEnd
  oConnector.Direction = "Source -> Destination"
  oSourceEnd.Cardinality = "1..*"
  oTargetEnd.Cardinality = "1"
  oSourceEnd.Navigable = "Navigable"
  oTargetEnd.Navigable = "Unspecified"
  oSourceEnd.Update
  oTargetEnd.Update
  oConnector.Update

After the Updates:
oConnector.Direction = "Source -> Destination"
oSourceEnd.Cardinality = "1..*"
oTargetEnd.Cardinality = "1"
oSourceEnd.Navigable = "Navigable"
oTargetEnd.Navigable = "Unspecified"

In the DB:

Code: [Select]

select  rel.ea_guid, rel.Direction
from    t_connector rel
where   rel.ea_guid = '{43839C7A-F120-43d1-8B85-328F89BA9AE6}'
Direction = "Destination -> Source"

The flip on the t_connector table occurs after the first update statement
oSourceEnd.Update

After that runs, the magic happens

[Geert Bellekens]

In general it is enough to set the direction. You shouldn't touch the Navigable properties.
Direction and navigability in EA depend on each other, and you get some weird results if you modify both.

Also the order in which you update stuff (or not) matters.

PS. I still have no clue what you are trying to achieve here.  Are you only trying to update the cardinality fields?

Geert

[ejafman]

What am I trying to achieve:
Modelers can enter a ton of data into a spreadsheet. They can change anything their big heart desires. If they do not pass a GUID for the relationship, a new connector is created. They can change source and targets if they want.
Therefore, the code I sent was a bare minimum, in order to try to figure out what is happening on this specific issue.

I even broke it down further. Running the following changes t_connector.Direction to "Destination -> Source", even though at the start it is "Source -> Destination":

Code: [Select]

  Set oConnector = eaRepo.GetConnectorByGuid("{43839C7A-F120-43d1-8B85-328F89BA9AE6}")
  Set oSourceEnd = oConnector.ClientEnd
  Set oTargetEnd = oConnector.SupplierEnd
'  oConnector.Direction = "Source -> Destination"
  oSourceEnd.Cardinality = "0..*"
'  oTargetEnd.Cardinality = "1"
'  oSourceEnd.Navigable = "Navigable"
'  oTargetEnd.Navigable = "Unspecified"
'  oTargetEnd.Update
  oSourceEnd.Update
  oConnector.Update

I also tried to change the ordering, as per an older thread that you actually commented on, so that the update was first called on the Target(Supplier) end, and the same behavior occurs.

[ejafman]

FYI...I even commented out the change to cardinality on oSourceEnd element, and the direction still changes after running the update on the oSourceEnd connectorEnd object.

[ejafman]

I think I have tried every combination of updates to the connector...setting the "Navigable" values on first the client end, then the supplier end, the Aggregation value, etc. etc. and even though the actual object shows direction = "Source -> Destination", when the connector is updated to the database, the Destination flips to "Destination -> Source".

Ouch...can't figure out what I'm doing incorrectly. I'll keep playing, but unfortunately, I have some real deadlines to do some actual modeling, so this may have to wait a couple of days. .

Aoppreciate all the feedback so fay, let's me know just what may be involved in this matter-anti-matter occurrence.

[Eve]

In UML 2.5.1 the navigability of an end is determined by whether it is contained in the navigableOwnedEnd. But there are 3 different notations that are relevant. "Navigable", "Non-Navigable", and "Unspecified".

For legacy reasons EA has two different ways to set this information and when you change one, the other will be updated.

The direction "Source -> Destination" corresponds to the Destination being navigable and the Source not being navigable (but it could still be notated with unspecified). "Destination -> Source" is the opposite. This works in the GUI because you can only change one at a time.

In the API it isn't quite as clear-cut, but the first update call is performing the same validation as the GUI

Code: [Select]

  oConnector.Direction = "Source -> Destination"
' ...
  oSourceEnd.Navigable = "Navigable"
  oTargetEnd.Navigable = "Unspecified"
  oSourceEnd.Update
  oTargetEnd.Update
  oConnector.Update


The oSourceEnd.Update updates the connector direction because it's incompatible with the value for Navigable that is being saved.

The answer is to only include one method for setting the navigability in your spreadsheet.

[ejafman]

Thanks, Eve, for your input...but it has only confused me more (perhaps it could just be such a "newbie" on EA).

In the GUI, I create an "Aggregation", by dragging from my "Source Class" to my "Target Class", and the values are the following:
Direction = "Source -> Destination"
Source Class.Navigability = "Navigable"
Target Class.Navigability = "Unspecified"

Are you saying that the "Destination" is this GUI example is wrong, given the values for Navigability I specified above? Or am I not understanding something. Because after dragging, and creating, the Destination(Target Class) definitely says "Unspecified".

Also, as an FYI...I have yet to even include the "Direction" in the spreadsheet, only source class, target class, aggregation, and cardinality. I just noticed the behavior I am witnessing by the pesky arrow showing up in the GUI on the "Source" side, which led me to this forum.

E

[ejafman]

So...Eve. In the GUI, I changed the source to be "Unspecified", and the Target to be "Navigable".

The Direction did indeed stay "Source -> Destination".

So, when creating a new Aggregation, basically you are saying that the navigable ends are being saved incorrectly, right?

I look at two Aggregations in the diagram, with the source and destination "Navigability" set in total opposite, and the Direction both = "Source -> Destination" and they look the same.

In t_connector, the only two columns I see closely related, and which have been mentioned in previous threads, are:
"SourceIsNavigable"
"DestIsNavigable"

SourceStyle on the "fixed" connector has "Navigable=Unspecified", DestStyle has "Navigable=Navigable"
SourceStyle on brand new connector has "Navigable=Navigable", DestStyle has "Navigable=Unspecified"

And other values for both rows are set the same, except the "fixed" one has SubType = "Weak"

Running the following on the repository:
select count(*)
from t_connector
where Direction = 'Source -> Destination'
and SourceIsNavigable = 0
and DestIsNavigable = 1
and instr(SourceStyle, 'Navigable=Navigable') > 0
and instr(DestStyle, 'Navigable=Unspecified') > 0

give me 354 "Incorrect" Aggregations.

Ouch

[Eve]

I'll be honest. Everything I said was based off my memory and I didn't try to create an aggregations. I'm not going to comment on how they are created.

There are also special cases for Aggregation connectors because they date back to before UML 2.0. If you want to be strictly UML conformant just use Associations instead.

You should definitely ignore the SourceIsNavigable and DestIsNavigable columns on t_connector. They are boolean values and we want to store non-boolean values for navigability. The result is that they aren't used.

[ejafman]

np...thanks for the input. I think the modeling team here really isn't too concerned about the actual underlying source and destination, just as long as the "diamond" shows up on the right side.

There are several in which the directional arrows are used, which, I assume, have been flipped correctly, since the modeler had to set them manually himself/herself, in order to show the directional arrows they were conveying.

E