Forks and Joins Missing from Project Browser

[philchudley]

I am using the latest build of EA and have just noticed that UML Forks and Joins do not appear in the Project Browser, depsite the fact that they have the Properties as all other UML elements.

In addition, there is no functionality to "Find in Project Browser" ... not surprising since they are not there I guess!

Is this deliberate on the part of Sparx, and if so why? After all all other UML Activity elements appear in the Project Browser as usual.

Cheers

Phil

[Frank Horn]

This seems to be deliberate. The ways of Sparx are impenetrable.

Anyway, not only forks and joins are missing, but also concurrent state regions. And while forks and joins are at least saved with other model data, the containment of a substate in a region is only saved with the diagram (i.e. if you export to XMI without diagrams, the information is lost).

Visual Paradigm shows regions in the browser and lets you drag states underneath regions there...

[beginner]

Notes and boundaries are also not visible. Relations are 2nd class (or 1st class??) and placed in a different window than the Project Browser.

b.

[lmunday]

I see that this discussion is over 7 years old, but this feature is still missing and I can find no effort to address this bug.
Decisions/Merges are treated as object with properties and can be referenced from anywhere in the model by copying and pasting a link to the object or by dragging and dropping from the project browser.
Fork/Joins are treated as object with properties and can be referenced from anywhere in the model by copying and pasting a link to the object, but not by dragging and dropping from the project browser because they cannot be found in the project browser.
Why? These items are so similar, there is not obvious reason (that I can see), and every other activity diagram element is displayed in the project browser. What is special about  fork/joins?

[lmunday]

Might there be some relationship to this issue?

[Paolo F Cantoni]

We separate out items from the diagrams.  The items are in their own branch of the Repository (in folders grouped by metatype).  So how do we find those items that can't be viewed in the Browser?

We use diagrams as proxies for the items themselves.  So for example, we have a Notes folder and place a diagram which has each Note we want to reuse in it.  The diagram is visible in the browser so we open that and copy the item as a link to the desired diagram.  A PITA, but at least we can find the things!

HTH,
Paolo

[Eve]

In my opinion, the bug is that these things can be copy and pasted to a new diagram without creating a duplicate.

If I'm generous, one fork or join being used in multiple places is confusing.  I'm more included to describe it as disastrous.

Notes, text and boundaries are just properties of the diagram, so shouldn't really be re-used either. At least re-using them doesn't have modeling implications.

[Paolo F Cantoni]

In my opinion, the bug is that these things can be copy and pasted to a new diagram without creating a duplicate.

We're not of the same opinion - but we've discussed this before. 

If I'm generous, one fork or join being used in multiple places is confusing.  I'm more included to describe it as disastrous.

Well, in my opinion, it's not much more disastrous than any arbitrary shape being connected to other shapes by different lines in other diagrams.  On any given diagram you're seeing a restricted view.  For example, is it any more correct to hide a line to another shape (and remove that shape) to or from the fork/join on the only diagram it is on?  I strongly would argue it's not.  I agree these are not good practices, but...

Notes, text and boundaries are just properties of the diagram, so shouldn't really be re-used either. At least re-using them doesn't have modeling implications.

Obviously, they aren't - they are just objects like any other.  The ONLY such object that should be the property of the diagram is the title block, which conceptually is a component of the diagram and shouldn't be implemented in t_object anyway.  Indeed, unlike the other types you mentioned, when you paste the object into the destination diagram, it takes on the values of the destination diagram rather than retain the values in the original diagram!

But it's Friday!  So have a good weekend!

Paolo