Cross-package dependencies

[cwilkinson]

I am attempting to figure out how to manage cross-package dependencies while using EA. I have a team of 3 people and I would like to implement some type of version control to the model. Currently we are looking at using either Controlled Packages or just have a model master who imports XMIs of the various packages into a master model once a user is done creating a model. My question is this. How do you manage cross-package dependencies using these approaches? Currently, using a 3rd party VCS is out of the question for now so we are attempting to use the tools that are built into EA. Any assistance would be GREATLY appreciated.

[Geert Bellekens]

I think your choices are to
a. Use a third party VCS
b. Not use versioning at all.

Any way, if you decide to implement version control you should really be careful with dependencies between controlled packages.
Always make sure to avoid cyclic dependencies, because that will get you into trouble.
Another hint that I've seen a few times is to import package xmi's twice, to ensure all links between packages have been reconstructed.

Geert

[DanG83616]

We use version controlled packages. We have to be really careful to make sure that packages are added to a private project in bottom-to-top order. Above all, before checking in a changed package, make sure that all of its referenced packages have also been loaded.

Let's say you have package A and it depends on B. You might need to make a change to A that doesn't involve and of the relationships to B. You make a quick private project and check out A, make the change and check it in. You just LOST all A's references to B!

I don't have a clever way around this and have been getting by okay by just being careful. It is probably possible to write an script that you can use to check for unresolved references before checking in. I bet Geert could whip that out in minutes!

I thought I was clever and created a package dependency diagram for each of my packages. Not a bad idea regardless of the VC issue. Unfortunately, that diagram is not a guide. If a package is not loaded then the diagram just doesn't show the package. Pretty useless if you don't already know what packages should be there.

Despite this risk of losing references, the solution has been workable.

As Geert said, avoid cycles. You'll really want to do that anyway so whatever trouble EA gives you with resolving cycles is just one more concrete reason to not have cycles. We package each component in its own package and interfaces are not allowed in component packages. They are packaged separately so that it is easier to avoid cycles. Two components packages that might otherwise depend on each other only depend on an interface package instead.

We have components that are nothing more than assemblies of other components. These packages don't have any actual classes in them but hold the component definition and composite diagram for the assembly component as well as interaction diagrams. This keeps the dependencies formally going in one direction.

HTH,
Dan

[cwilkinson]

Thanks for the input guys. My prayers were actually answered and we are going to be using Clear Case!

Do the same issues exist with using Clear Case? I am really new to all this modeling stuff so please bear with me.

Thanks!