Visual indication for elements that is shared in multiple diagrams

[BobM]

Dear,

Sometimes people copy full structure diagrams and end up deleting elements that were already shared, having to resort to backups because the confirm deletion isn't eough.

Is it possible to add a visual representation for all elements on a diagram that are used in more as one diagram?

A possibility is to add a display all shared elements in a diagram in which these elements are highlighted
Example: all capabilities are shared and button is active


A possibility is to add an icon to elements where Element useage has more as one result
example:


Both suggestions aren't exclusive to eachother

[Paolo F Cantoni]

Hi Bob,
Interesting Idea!
However, for us, each item gets its own Neighborhood diagrams, so it is always in multiple diagrams.
Perhaps, if we limited the "multiples" to those diagrams that aren't composite diagrams of items.

Have you submitted a Feature Request using one of the links below?
Paolo

[Geert Bellekens]

I'm not convinced we need something like that.
We already have a warning when deleting something, and there is now also a button to give you the traceabilitie view of the item you are deleting.

For me this is mostly a user education issue. Teach them the different between delete (remove from diagram) and delete (delete from model)

No amount of obscure icons is going to stop these users I'm afraid.

Geert

[qwerty]

I think the usual thing is that you have elements in more than one diagram simply to shed light onto them from different perspectives. There should be a better way to see orphans in the browser in contrast (you can search for them but nobody does use this function in practice).

q.

[Paolo F Cantoni]

I think the usual thing is that you have elements in more than one diagram simply to shed light on them from different perspectives. In contrast, there should be a better way to see orphans in the browser (you can search for them, but nobody uses this function in practice).

q.

Since Diagrams don't really exist in UML, it's a bit hard to call items, not on any diagrams, "orphans".
It's all part of EA's misnaming of things.

Paolo

[BobM]

I'm not convinced we need something like that.
We already have a warning when deleting something, and there is now also a button to give you the traceability view of the item you are deleting.

For me this is mostly a user education issue. Teach them the different between delete (remove from diagram) and delete (delete from model)

No amount of obscure icons is going to stop these users I'm afraid.

Geert

I agree this shouldn't be necessary, but improved prevention of having to resort to recovering backups, losing work in the progress is a significant QOL improvement in my book.

After investigation I found out the reason for the issue was using full structure for duplication on the folder instead of using copy diagram for each diagram
Copy diagram gives the option for shallow/deep/smart which explains what happens, full structure for duplication apparently keeps some shared elements where the user assumed it would have been duplicated.
Where I Agree with Sparx keeping the shared elements it keeps after duplication I do understand the confusion for end-users as Sparx enables multiple ways to reach a goal.

Adding visibility to know what happened in the backoffice should be/have been a great help to prevent this from happening

[Modesto Vega]

It is an interesting feature and its introduction, or a variation of it, will be very welcomed. It certainly will facilitate collaborative working and avoiding "stepping into each others toes".

It is way too easy to delete or rename something in a large repository without considering the implications. The deletion warning is not enough; it will only be enough when it provides an overview of impact of the delete - i.e., the diagrams and related elements affected.

[SNIP]
I think the usual thing is that you have elements in more than one diagram simply to shed light onto them from different perspectives.

Agreed, the whole point of having the elements in more than one diagram is to show them from different perspectives.

There should be a better way to see orphans in the browser in contrast (you can search for them but nobody does use this function in practice).

[SNIP]
Since Diagrams don't really exist in UML, it's a bit hard to call items, not on any diagrams, "orphans".
It's all part of EA's misnaming of things.

Notwithstanding Paolo's comment, there should be a better way through the user interface to identify which elements do not appear in diagrams, have no relationships to other elements, and their age - i.e., how long they have been in that state.

[wivel]

Hi

Interesting discussion. I'm sort of with Geert that we already have tools needed to examine whether an element is used in other diagrams. Being used in more than one diagram is just one scenario when deleting elements, and a visual representation in this case, will not prevent you from deleting things physically, that should not have been.

I have personally physically deleted elements from the model that should not have been deleted, even if it was present in only one diagram, or none, for that matter.

Having a visual indicator might give a false sense of security when deleting elements, especially for not so experienced users.

Henrik

[Modesto Vega]

Hi

Interesting discussion. I'm sort of with Geert that we already have tools needed to examine whether an element is used in other diagrams. Being used in more than one diagram is just one scenario when deleting elements, and a visual representation in this case, will not prevent you from deleting things physically, that should not have been.

I have personally physically deleted elements from the model that should not have been deleted, even if it was present in only one diagram, or none, for that matter.

Having a visual indicator might give a false sense of security when deleting elements, especially for not so experienced users.

Henrik

I am not sure I fully agree with this statement. This is the recursive SQL statement I had to write to find all elements not appearing in diagrams and directly or indirectly belonging to a package in our SQL Server repository.

Code: [Select]

WITH generation AS (
    SELECT
Package_ID
,ea_guid Package_GUID
    ,name Package_Name
,Parent_Id
,0 AS generation_number
    FROM t_package
    WHERE parent_id = 1
and ea_guid = '<Package GUID goes here>'
UNION ALL
SELECT
child.Package_ID
,ea_guid Package_GUID
,child.name Package_Name
,child.parent_id
,generation_number+1 AS generation_number
FROM t_package child
JOIN generation g
ON g.Package_ID = child.parent_id
)
SELECT obj.Object_ID elObjectID,obj.Name elName, Object_Type elType, Stereotype elStereotype, dobj.Diagram_ID
FROM t_object obj
inner join generation gen
on obj.Package_ID = gen.Package_ID
left outer join t_diagramobjects dobj
on obj.Object_ID = dobj.Object_ID
where dobj.Diagram_ID is null
The SQL statement is not straightforward and cannot be used by Sparx Enterprise Architect because of the CTE. It can only be run directly on the database.

[Geert Bellekens]

There is a fairly simple alternative that you can run as an SQL Search in EA using the #Branch# macro:

Code: [Select]

select * from t_object o
where o.Package_ID in (#Branch#)
and not exists
(select do.Object_ID from t_diagramobjects do
where do.Object_ID = o.Object_ID)
No need for complicated recursive queries. This works based on the package selected in the project browser.

Geert

[timoc]

I think this icon feature, if considered, should be more abstract than a de-duplication like rule.

The abstract feature would be an extra icon+tooltip text generated by a scriptlet. That way, the icon can be used to support user specific model validation/diagram helper rules. Possibly two icons, an icon associated with the diagram rules and an icon associated with the model rules...

[Modesto Vega]

[SNIP]
No need for complicated recursive queries. This works based on the package selected in the project browser.

Since we do not have a repository per (new or existing) system or dedicated repositories for specific programmes/projects, recursion is needed. If we had a repository per system or programme/project, recursion will not be needed.

Sparx needs to pay more attention to the "E", after all the product is called "Enterprise Architect" not "Application Architect"

[Geert Bellekens]

[SNIP]
No need for complicated recursive queries. This works based on the package selected in the project browser.

Since we do not have a repository per (new or existing) system or dedicated repositories for specific programmes/projects, recursion is needed. If we had a repository per system or programme/project, recursion will not be needed.

Sparx needs to pay more attention to the "E", after all the product is called "Enterprise Architect" not "Application Architect"

Did you try the #Branch# macro?
This gives you a list of all packageID's starting at the current package, recursively including all child packages; exactly what you are doing with your recursive query.

The difference is that EA does the recursive part for you.

Geert
In that case EA does the recursive search for you

[Modesto Vega]

If you are suggesting to use a ModelView with a SQL statement that uses the #Branch# macro in the where clause, this appears to be returning the right results. I tried the #Branch# macro in previous version (< 15) and never got the right results.

Unfortunately the ModelView has no functionality other than reading the data. For example, I cannot select a single element, right click on it and finding in the project browser.

I am not sure if I can achieve the same result with a custom search, I cannot quickly recollect if a custom search is package sensitive.

[Geert Bellekens]

If you are suggesting to use a ModelView with a SQL statement that uses the #Branch# macro in the where clause, this appears to be returning the right results. I tried the #Branch# macro in previous version (< 15) and never got the right results.

Unfortunately the ModelView has no functionality other than reading the data. For example, I cannot select a single element, right click on it and finding in the project browser.

I am not sure if I can achieve the same result with a custom search, I cannot quickly recollect if a custom search is package sensitive.

Yes you can. I use #Branch# in a lot of SQL Searches

Geert