Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - mariop

Pages: [1] 2
1
Bugs and Issues / Setting duration constraint in Seqeuence Diagram
« on: June 08, 2023, 11:10:32 pm »
Hi,

I need to rebuild some sequence diagrams and have hard time finding a way to properly set duration constraint between messages as shown here:
https://imgur.com/qssmWvM

I can set the one marked in green my right clicking on first message -> Timing Details and then set comment to "Duration constraint between messages" field.

But how to define between which messages, I can't find. I only get to set duration constraint between two closest one.

Can someone shed some light here?

Thanks in advance!

Best regards,

Mario.



2
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.

3

Instead they are updating the SourceStyle and DestStyle columns and adding another key-value pair like: "Navigable=Non-Navigable;"

Geert



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.

4
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.

5
Hm. Are you sure about this?

For any given combination, I see Direction value changes for these rows, but Navigable values remains 0.

Mario.

6
OK, here is example:


First one is without mistery arrow, second one is with it.
I see no difference (Direction won't fix it)

7
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.

8
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.

9
Hi,

Well, that is another thing: Arrow will not disapear with changing direction to "unspedified".




However, changing it to "Destination to Source" makes the arrow jump on left end (which is expected):


Something is fishy here. I am testing this on version 16.0.1605. (trial license).

10
Hi,

It is the same relation type.

Properties for that one (the one with the arrow):


--
Mario.


11
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:

12
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:


Migrated in v16:

13
I thought as much.

There is, however, another possibility: someone who created that diagram could actually just write attribute type in the box. That way attribute type is sort of defined, but can't be refefrenced to certain object.

I found plenty of those while cleaning repository.

The same goes for custom stereotypes: I ended up with 2 custom stereotypes for classes visible, but actually not present in UML Types -> Stereotypes.
Once I defined them again in v16 and set custom color codes, all diagrams were shown with those custom codes (as it should be in the first place).

I find EA being too loose when it comes to definition and referencing of objects. It is very easy to come up with something which only looks ok, but is actually not well defined.

14
Hi,

Almost certainly was.

Or... What happens if defined attribute type object is moved to another package within EA? How will EA handle links to it? Will it be able to link to it, or will it point to non-existing object?

Because, that might also happen at source system at some point.


15
Well, that is a very good point. I checked and, indeed, those types are missing, actually.

Even worse, I checked at the source - they are pointing to nonexistent objects. Well, this solves the mistery and gives us some work to do too. :)

Thanks for the tip!

Best regards,

Mario.

Pages: [1] 2