Book a Demo

Recent Posts

Pages: 1 ... 5 6 [7] 8 9 10
61
Hi Viking,

I am afraid I still do not quite understand the issue; however, this forum is not the appropriate place to solve individual problems related to a specific add-in. Could you please email me the details, along with an example project or the steps to reproduce the error?

As far as I know I cannot insert an image.

I created a ArchiMate3::ArchiMate_Serving realtionship. The mcp server created an association with profile "ArchiMate3". But the checkbox for the stereotype "ArchiMate_Serving" has not been set.
62
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
63
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.
64
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
65
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
66
Bugs and Issues / Re: Packaging component
« Last post by Martin Merkel on April 27, 2026, 04:36:10 pm »
Not that I would claim that I've successfully used or understood packaging components, but the other day I've come across a scenario where they might help.
I'm working on a model for communication systems that attempts to follow the OSI layering structure. At the application layer I have multiple alternative communication profiles that I've put into components, with each of the protocol entities modeled by a class. But now I considered assembling the corresponding protocol service descriptions and the protocol descriptions into packages, not to clutter my project structure. The service description contains interfaces etc., the protocol descriptions sequence diagrams. However I cannot put a package below a class, nor a component. I can on the other hand put them under a packaging component.
Anyway, I figured out that I cannot change the type of a component to packaging component, the three dots won't let me do that, so I have to rebuild the structure.
Martin

Ps: I cannot add a port or an interface to the packaging component as for classes and components though, probably because it's a package  :(
67
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.

68
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.
69
Hi Viking,

I am afraid I still do not quite understand the issue; however, this forum is not the appropriate place to solve individual problems related to a specific add-in. Could you please email me the details, along with an example project or the steps to reproduce the error?
70
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.
Pages: 1 ... 5 6 [7] 8 9 10