Strangely enough, I was contemplating the high-church meaning of this type of thing myself yesterday.
At the end of the day, there is no real dependency between two UML
packages of this nature. The dependency only exists btweeen the
package contents and given the way you have described it ... only in a particular implementation of a model.
IOW in the high-church of UML, AFAICT, the dependency of the contents of one package on some other package is to be expressed as a/some "required interfaces". When the beast is created, other packages will provide these services via "provided interfaces". Now strangely enough, these do exist - as adornments for component elements, and even further strangely enough the UML definition of a component "that which may be deployed separately" sounds 'zactly like a library package to me.
What I'm meandering around trying to say is that the dependancy only exists at the implementation level. Only when you create that specific version of that specific library do you get a dependancy or, if you like, I'll replace your library with mine and c.p. all will still be well (or we'll get dll hell
).
The "provided" and "required" interfaces on components are not the same thing as exposed interfaces at the code level i.e. they are not contractual items. They are at best "a group of required/provided services that will be needed at implementation for the entire beast to function properly".
So, in short, I doubt whether there would be a "automatic" way to create these things.
hth
bruce
