Model And Transformation Management
*Generative Model Transformer*
First off lets make it easy on ourselves and NOT worry (yet) about distributed tool use (we can have this as an eventual goal, along with a "visual aspect). Web based or not I venture to say that whatever mechanisim we choose, once we introduce "distributed" use then the same problems will have to be addressed. --Jeff
Sure the distributed can come later, although once we have a web-based interface, the "only" ;-) other thing we need is a good central repository that can store models, see below. We could either use an SQL database or use an object database. What such a repository should allow you to do, is to open up a model for editing to a (small) group of people. --Jorn
Ultimately what I think you need is:
- a BA may sit together with a customer, capturing model information, while a designer is watching the model evolve in a different location, who may then modify bits and pieces.
- Similarly two designers/developers may collaboratively work on a shared model even though they're in different locations.
- Locking: As long as the models are accessible from multiple locations and updated in a repository as changes occur, it may be sufficient for one person to have a lock and others being able to watch the changes (live!). This works if the editing lock on a package (model part) can be passed around in a small virtual team like a token. (Like using a walkie tackie, you aquire the lock by pressing a button that signals your request to the current owner of the lock). The most important thing though is very simple: a locking mechanism at a "package" level, that gives access to a manageable model part to one person. Basically it amounts to shared workspaces for collaboration. If models get large, several separate workspaces can be used by different groups of people, with each workspace dealing with a separate package (model part). But to start, we can keep it very simple: One person locks a package and works on it and then check it back in. The "repository" can consist of XMI files and versioning is CVS (or "Subversion". Have you seen that yet? It's apparently "next generation" CVS). --Jorn
- It works on almost all platforms and is (nearly) identical in appearence.
- We have access to a good cross platform servlet reference implementation that is open-source (used by eGen, so we know it works).
- We know it can work, even if we can't vouch for the distributed part. However, as I said earlier this is an issue that would have to be address regardless of the specification medium choosen.