Tracing communication path assoications

[kepNCI]

When viewing the traceability, links such as associations can be included using the "Other Links" , however communication path connections, which is a specialized association relationship are not listed in the trace.

WHY?

I think this is a bug unless there is away to include communication path association relationships in the trace.

Karl

[qwerty]

We know that EA is consistently inconsistent. You should report that as bug. Not unlikely that you are the first stumbling over that (or really feeling enough pain to ask here).

q.

[skiwi]

We know that EA is consistently inconsistent. You should report that as bug.

Odd you should say that, I've always thought of it being inconsistently consistent.  [smiley=undecided.gif]

[qwerty]

Each time I discover another strangeness (just a couple of minutes ago (my tears are still flowing) that oddity where Allow Duplicates for Ports is stored) I have the feeling that this is planned. In my imagination I see the developers and plumbers sitting in a room and discussing how they can spoil the design a bit more. So it must be consistently inconsistent.

Thinking of the design to be inconsistently consistent would presume the designers to be too dumb to get it done. That's likely not very polite.

q.

[AndyJ]

I'm inclined to believe that it is developers bending over backwards to introduce functionality requested by users, and accidentally warping the design in the process.

Not to mention... as applications get older and more complex, there is a general tendency for all code to get a little "crusty"

 

[qwerty]

Sadly, yes. My belief is that it's the architect's role to get rid of that crust every now and then. Not to put paint on it once again.

That's the difference between Apple and Mickeysoft. The first get rid of old stuff very fast (which causes a lot of grief one every first or second year). And the latter causes permanent (maybe less) grief as you have to still care for DOS peculiarities from 30 years back. Two worlds and Sparx definitely live in the M$ world.

q.

[skiwi]

Indeed. The design needs to be consistent, and when new features are added old features must be updated to match (look at the swimlanes/matric/kanban to see this in spades).

I was noticing today the (whiteboard) thin lines up, down, left, right. (but not double ended).

Why not have designed two arrows - single ended and double ended, and allowed any degree of rotation.
Satisfies more use cases (more orthogonal).
Throw in the ability to allow them to be curved - now that us useful.

[kepNCI]

As for the tracing of communication path associates, developers have confirmed and logged it as a bug.

[Graham_Moir]

Well on the surface that's good,  but only time will tell whether it actually gets fixed.

[skiwi]

Why not have designed two arrows - single ended and double ended, and allowed any degree of rotation.
Satisfies more use cases (more orthogonal).

Add to that a line with no arrow ends. Since the "whiteboard line" isn't a line at all, its a connector.

(PS searching the forum seems to have a few bugs,
e.g. searching for "arrow" doesn't find "arrows", and searching for all posts by use user - in this case moi - doesn't seem to work at all for me)

[qwerty]

(PS searching the forum seems to have a few bugs,
e.g. searching for "arrow" doesn't find "arrows", and searching for all posts by use user - in this case moi - doesn't seem to work at all for me)

I had the same impression yesterday and switched to Google Sparx Groups where I found what I was looking for.

q.