Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: mariop on October 04, 2022, 07:43:04 pm
-
Hi,
I am seeing some (not all, and that is annoying) compositions in v16 of diagrams having direction arrow. On same diagrams in v14 that is not the case.
I checked definition of relation and didn't find anything I could point at to be cause of it.
In this example in both cases direction is defined as: Source -> Destination.
It has to be something causing this. Anyone had something similar?
Original in v14:
(https://i.imgur.com/LlF2Rr4.png)
Migrated in v16:
(https://i.imgur.com/uawBorl.png)
-
If it's "Source -> Destination" then there should be an arrow. (and v14 is wrong in not showing the arrow)
If you don't want to show the arrow you can choose "Unspecified"
Geert
-
Hi,
Thanks for confirmation. I suspected it, but I am a bit confused - I see some similar with direction defined the same way with no arrow at all.
Example:
(https://i.imgur.com/CRsNf0r.png)
-
Ah, but your second one is showing an Aggregation, is that the same for the relation between PartyAddress and Party, or is that an Association?
Geert
-
Hi,
It is the same relation type.
Properties for that one (the one with the arrow):
(https://i.imgur.com/ViWy7FL.png)
--
Mario.
-
The direction for the other should be Unspecified. If not: report a bug.
q.
-
Hi mariop,
I am sure that the drawing is affected by the following change in the Readme file of the version 16.
Improved the display of arrowheads on Aggregations and Compositions
In my some diagrams (basically made many years ago), I can see the same situation.
I think this is not a bug, but because of the bug fix. I think that the arrowheads should be shown naturally, but EA did not show the arrowheads as a bug in the older builds.
Anyway, fixing them manually one by one is crazy. I have made a patch file for Japanese customer like below. Save the XML as a file with 'xml' extension, then import it via Settings ribbon | Model | Integrity | Run Patch.
---
<?xml version="1.0" encoding="UTF-8"?>
<EAPatch>
<EAPatch.content>
<PatchDescription>This patch will remove arrows of Aggregations.</PatchDescription>
<PatchQuery> SELECT Count(*) AS NumRecords FROM t_connector WHERE Direction = 'Source -> Destination' AND Connector_Type = 'Aggregation';
</PatchQuery>
<PatchSQL> UPDATE t_connector SET Direction = 'Unspecified', DestStyle = 'Union=0;Derived=0;AllowDuplicates=0;Owned=0;Navigable=Unspecified;' WHERE Direction = 'Source -> Destination' AND Connector_Type = 'Aggregation';
</PatchSQL>
</EAPatch.content>
</EAPatch>
---
This is not an official patch, but it might help you. Please backup your project before running the patch.
HTH,
-
I would report it as a bug because it's clearly inconsistent.
But in the end, if you don't want to see the arrows, you'll need to use "unspecified" as direction.
Geert
-
Hi,
Well, that is another thing: Arrow will not disapear with changing direction to "unspedified".
(https://i.imgur.com/AefyJ4b.png)
However, changing it to "Destination to Source" makes the arrow jump on left end (which is expected):
(https://i.imgur.com/LIb9nTk.png)
Something is fishy here. I am testing this on version 16.0.1605. (trial license).
-
This is not an official patch, but it might help you. Please backup your project before running the patch.
HTH,
I was never aware of this possibility to run a patch. I did these running a script with said precautions (sandbox, backup, etc.). Anyhow, is this something official or just leakage?
q.
-
Hi,
I checked in the database for two aggregations (one with mistery arrow, and one without it). When I change Deirection to "Unspecified", it gets changed in database properly, but in class diagram arrow remains.
Only for certain aggregations, though. I can't make it consistent, nor can I determinate what might cause this.
Looks like a bug, but unsure.
Best regards,
Mario.
-
There are in fact three separate columns that determine the direction, so there is a chance that there is an internal inconsistency that causes this behavior.
- t_connector.Direction
- t_connector.SourceIsNavigable
- t_connector.DestIsNavigable
Maybe, if you are lucky, a project integrity check solves this.
Geert
-
Thanks for the tip. I will look into it.
I already ran project integrity check and fixed all issues at some point. No new issues atm (according to it).
Mario.
-
OK, here is example:
(https://i.imgur.com/9XS2X0x.png)
First one is without mistery arrow, second one is with it.
I see no difference (Direction won't fix it)
-
The first one is correct, the second one is not correct.
If the direction is "Source -> Destination", then the DestIsNavigable should be 1
The Direction should really be a derived field based on the the values of SourceIsNavigable and DestIsNavigable.
Geert
-
Hm. Are you sure about this?
For any given combination, I see Direction value changes for these rows, but Navigable values remains 0.
Mario.
-
Never thought about this, but having the properties this way looks like bad redundancy. No wonder there are issues.
q.
-
Hm. Are you sure about this?
For any given combination, I see Direction value changes for these rows, but Navigable values remains 0.
Mario.
Hmm, I did a quick test, and it seems that indeed in v16 the columns SourceIsNavigable and DestIsNavigable are no longer used, they stay at 0 (but "old" values are not updated)
Instead they are updating the SourceStyle and DestStyle columns and adding another key-value pair like: "Navigable=Non-Navigable;"
Pff, so they had a normalized separate column for this information, but they decided to not use that anymore and instead hack this info into the "style" columns? :o :o :o
If we are going that way, we might as well get rid of all those pesky columns. Instead each table could have a single column with keyvalue pairs!!
Not sure since when this has changed exactly, but it might be a serious problem for those of us thinking about upgrading to v16.
I would definitely report it as a bug.
Geert
-
The problem, in part, comes about because Sparx has conflated Directionality with Navigability. One property (Directionality) relates to how the line should be drawn. The other (Navigabilioty) with whether the arrows should be drawn.
We have standardised on ALL relationships having directionality = Source -> Destination and ensured the semantics are therefore correct. In over 200,000 relationships we maintain, all are so designated. Navigability is set as required.
While this conflation remains, different relationships created at different times by different versions of EA will behave differently.
HTH,
Paolo
-
It seems like this change dates from before v16.
I tested this in v15, and the IsNavigable fields remain 0 there as well.
Geert
-
Hm. Are you sure about this?
For any given combination, I see the Direction value changes for these rows, but Navigable values remain 0.
Mario.
Hmm, I did a quick test, and it seems that indeed in v16, the columns SourceIsNavigable and DestIsNavigable are no longer used; they stay at 0 (but "old" values are not updated)
Instead, they are updating the SourceStyle and DestStyle columns and adding another key-value pair like: "Navigable=Non-Navigable;"
Pff, so they had a normalized separate column for this information, but they decided not to use that anymore and instead hack this info into the "style" columns? :o :o :o
If we are going that way, we might as well get rid of all those pesky columns. Instead, each table could have a single column with key-value pairs!!
Not sure when this has changed exactly, but it might be a serious problem for those of us thinking about upgrading to v16.
I would definitely report it as a bug.
Geert
Sheesh!
"Navigable=Non-Navigable" is very confusing. If they were going to do that, then it should at least be "Navigability=Non-Navigable".
But as you ask, Geert, why change? Well, the reason would appear to be that they are now able to include an extrinsic value "Navigable=Unspecified". This is not possible where SourceIsNavigable and DestIsNavigable are boolean values.
I have found a number of connectors with Source unspecified, Destination Navigable, in line with my previous post.
If it had been my design decision (with no loss of generality - as the Mathematicians say), I would have STILL set SourceIsNavigable and DestIsNavigable to true if Navigable=Navigable for the respective end. That would have been better than false, regardless. But then, what would I know? I'm just a data architect who passed "Thinking 101".
Paolo
-
Pff, so they had a normalized separate column for this information, but they decided to not use that anymore and instead hack this info into the "style" columns? :o :o :o
If we are going that way, we might as well get rid of all those pesky columns. Instead each table could have a single column with keyvalue pairs!!
I presume that Sparx does not have any data architect (looking at the ever conflating StyleEx columns in various tables). So prepare for more confusion in the future.
q.
-
But as you ask, Geert, why change? Well, the reason would appear to be that they are now able to include an extrinsic value "Navigable=Unspecified". This is not possible where SourceIsNavigable and DestIsNavigable are boolean values.
One would think that, but if I look into my database I find values
* 1 => Navigable
* 0 => Unspecified
* -1 => Not Navigable
I really don't see why they would want to move from a clearly defined normalised scheme to a scheme that relies on descriptions somewhere in a text field.
Geert
-
OK, one thing is weird representation in database, but this non-consistency in class diagram (arrow being present only in some cases) is what is pretty annoying too.
And I can't seem to pinpoint correlation between values in database and cases where arrow is visible in class diagram.
Whatever I tried to change, I couldn't properly fix it (not to mention, I can't re-produce it at will on new class diagrams).
Mario.
-
But as you ask, Geert, why change? Well, the reason would appear to be that they are now able to include an extrinsic value "Navigable=Unspecified". This is not possible where SourceIsNavigable and DestIsNavigable are boolean values.
One would think that, but if I look into my database, I find values.
* 1 => Navigable
* 0 => Unspecified
* -1 => Not Navigable
I really don't see why they would want to move from a clearly defined normalised scheme to a scheme that relies on descriptions somewhere in a text field.
Geert
My Bad, I was looking at the original .eapx repositories where they are Yes/No (boolean) values. I see the SQL Server columns are int columns. Nothing like consistency! ::)
Since we have NO Not Navigable ends in our repository at the moment (we're only interested in the Navigable ends. For us, unspecified => non-navigable), I didn't see them.
Your last point above is EVEN more apposite!
Paolo
-
Instead they are updating the SourceStyle and DestStyle columns and adding another key-value pair like: "Navigable=Non-Navigable;"
Geert
(https://i.imgur.com/Mou1Q5o.png)
I see diff between one with arrow (19382) and one without it (19381). How it came to this, I have no idea. How to reproduce - no idea. :)
Mario.
-
Hi,
What can be concluded from this example? To file a bug? Or is it a feature? Maybe just very loose definition?
At the end, I would like to ditch those few arrows apearing in class diragram in EA16.
Thanks!
Mario.
-
This is not an official patch, but it might help you. Please backup your project before running the patch.
HTH,
I was never aware of this possibility to run a patch. I did these running a script with said precautions (sandbox, backup, etc.). Anyhow, is this something official or just leakage?
q.
Very interesting. I also never heard of this before, yet I found it in the online help (without any example): https://sparxsystems.com/enterprise_architect_user_guide/16.0/the_model_repository/runningsqlpatches.html (https://sparxsystems.com/enterprise_architect_user_guide/16.0/the_model_repository/runningsqlpatches.html)
The effort seems to be the same as writing a script, but I can see the advantage in not deliver a script for patch purposes that could remain in the EA project. A typical scenario is deleting or renaming tagged values in the MDG stereotype definition, and updating the existing stereotyped elements or attributes.
Thanks for the info Takeshi :D
-
On very rare occasions Sparx has released a patch in the past.
I think I remember only one such occasion in the last 15 years.
Geert
-
Thanks for the info Takeshi :D
Well, seems he has removed the post meanwhile. So it was a leak, I guess.
@Geert: you don't happen to have kept that single patch (I can't remember ever having seen one)?
q.
-
@Geert: you don't happen to have kept that single patch (I can't remember ever having seen one)?
No, I don't think so.
Geert