As you may be aware, Sparx introduced the concept of a Connector Proxy (which, in typical EAUI, they incorrectly named Proxy Connectors). The vertex (in t_object) is a proxy for the arc (in t_connector). It is one or other (or even both) end(s) of an arc, to/from an arc to a vertex or another arc. We are starting to use them more extensively, but we have struck a problem with package transport between repositories.
If a diagram has objects that are not in the package to be transported, then EA (correctly) creates an External Reference entry for the missing vertex. When we spot these missing vertices, we track them down and make sure they come over to the destination repository. Typically, but not exclusively, we transfer the package in which the missing vertices are located. The problem that we have with Connector Proxies, is that we can't (via the UI) determine which package these missing vertices are located. This is for two basic reasons:
1. Connector Proxies aren't visible in the browser
2. Although selectable, their properties can't be viewed using the normal [ALT+Enter] keyboard shortcut and are suppressed in the Properties Window. (Actually, by an EAUI trick, they can be made visible, but I'll leave that as "an exercise for the reader" )
We've done some analysis of Connector Proxy usage in one of our repositories and we find that there is NO correlation between the package associated with the Connector Proxy (t_object.Package_ID) and the package associated with EITHER of the ends of the arc for which it is the proxy (i.e. the t_object.Package_ID of the t_connector.Start_Object_ID or t_connector.End_Object_ID).
Now, conceptually, this is likely to be so! The arc does not have an associated package (since which of the two possible packages should we pick?). But unfortunately, the Connector Proxy DOES require an associated package - EVEN though notionally it might not. However, setting the Package_ID of the Connector Proxy to zero or null will trigger an error in the Integrity check
So, we integrity checked the repository with the imported packages and the "orphaned" Connector Proxies (which appeared as External Reference elements on the diagram) were picked up as errors and deleted. In fact, there are currently NO ProxyConnector vertices in the t_object table of the target repository.
The Sparxians aren't going to fix this anytime soon. But we are STILL left with a problem - how to get the appropriate Connector Proxies over to the target repository in a consistent manner?
At this point, I'm open to suggestions. I'll outline our current thinking and would appreciate if anyone can "blow holes" in it.
We have already separated our vertices (model items) from our diagrams (viewpoints) and we already have global folders for specific types of vertices - such as Legends etc. It seems reasonable to add another global folder for Connector Proxies and make sure that "under the covers" ALL Connector Proxies are relocated to that folder. We could then transport that folder in addition to the REAL package we are exporting and that way the Connector Proxies would move (whether they are needed in the target repository or not).
One problem with springs to mind is; if each repository has the same global package, keeping them in sync could be problematic. The ability to "shoot oneself in the foot" looms large! This might be solved by creating a separate folder for each repository, thus:
[Say we have two repositories "E" and "S", initially, S has NO Connector Proxies, but E has some. E's Connector Proxies are gathered into Connector Proxies.E folder. We transport a package P from E to S, having first transported the Connector Proxies.E folder to S. Because, each Connector Proxy has a Package_ID, it is not orphaned, even though it might not be used in S.
We then work on stuff in package P and add some more Connector Proxies whilst it is in S. These will be gathered into Connector Proxies.S folder. If we transport package P BACK to E, from S, we need to first transport Connector Proxies.S folder from S to E.]
I think this might work (or at least provide a working prototype).
Thoughts?
Paolo
