Paolo,
sorry about that! It's always the same when something complex seems clear in ones mind that it can be dam hard to write down clearly!
When I said "a model of models" what I meant was that an EA project can actually consist of more than one model and each model can consist of one or more packages. The important distinction between a model and a package is that the model specifies the path to the root of the model repository and which version control system is to be used. Hence the packages that make up a model all have to exist under this root path and use the same version control system.
And get this, EA allows you to make linkage between elements in separate models! So there is no loss of capability from splitting a single model into many models. (Note that links are stored with the source element in the XMI files and reference the target elements GUID. This means that only the source element package needs to be checked out to add a link, so plan carefully, but typically this allows requirements traces to be added without the need to check out the requirements packages. Neat!
)
So I hope that if you now re-read my previous post you will understand that by dividing a single monolithic model into a number of separate models that each one can be now be placed in a separate version control "place". In ClearCase terms this could be a unique VOB, or at least a separate model folder in the same VOB, for each model in the model (sorry, EA project). This means that each one can be separate base lined in your version control system.
So you could have an EA project that consists of a Requirements model, an Analysis model, and a Design/implementation model. And each one can be separately controlled, base lined, and issued to each team member or sub-teams (on larger projects).
The only caveat is that each team member or sub-teams must have their own working set and hence database. And then the problem is keeping everyone of these working sets in synch with the version control repositories. But since we're doing this in order to have control over who does what and when, then approved changes to individual models will be released to the other team members or sub-teams - won't they! And then these receiving (sub-) teams can decide when best to take the update and assess the impact of the change on their model and work - won't they!
Hope this helps, despite the excessive use of the word "model"!
Best Regards
Dave B.
