BOUML attributes an identifier to the main objects to resolve the references to the not already read objects when you load a project. This identifier is establish during the object creation and will not change later (except if you import a project into an other one), to allow several users to work simultaneously on the same project, this object identifier contains the identifier of the user creating the object. This explains why BOUML ask you to have an own identifier between 2 and 127.
These identifiers are also used to name the files memorizing a project, refer to Project files. The plug-out API define the UmlBaseItem::supportFile to know whose file(s) support a given item.
Notes : When it loads a project, BOUML checks the write permission of the file done through the OS or the applicative permission indicated inside the file. In the browser the writable objects are written in bold. When you load a project, this one must be consistent, else the references to the unknown items are removed and these unknown items are considered deleted.
When you are several working on the same project you have to choose between two ways :
In this case all the users work on the same project files, this means that no one has a copy of the project files. This is possible because when you do a save only the modified files are written. However this suppose at most one user may modify a given project file, else modifications made by several will quickly be done.
There are two way to allow at most one user to modify a file : to use the write permission set using your OS (difficult under Windows) with the help of File Control, or to use Project Control.
File control is a plug-out mainly dedicated to be an interface between BOUML and a file control like Clearcase, CVS or Subversion etc ..., however to use a file control may affect the write permission of the files.
Project control is a tool managing an applicative write permission optionally memorized in the project files associated to the packages. This allows to set the write permission independently of the OS you use.
In this case each user has an own copy of the project, and sometimes all the modifications done in parallel are grouped. You may adopt two strategies : to allows any user to modify any part of the project, in this case you will have to merge the modifications by yourself, or to allow only one user to modify a given project file.
Even the Project files are Ascii files, I may be difficult to merge several version of the same file, I know several companies use this way, but it is possible to not have to merge the modifications using the write protection through File control or Project control and to resynchronize the model using Project Synchro.
Let's suppose Bruno, Olivier and Annie work on the same project and decide to use Project Control and Project Synchro.
At the beginning an unique image of the project exist. If the project already exists, using Project Control you give the write access of the package to at most one person. If you start from scratch with an empty project, immediately create at least a sub-package for each, this may be changed later. Because the project itself is used to memorize generation settings and other global information, I propose you to decide immediately what are the settings and to protect the package supporting the project, this means it is not owned by Bruno, Olivier or Annie.
When the write accesses are set, duplicate the project files (in fact the directory of the project) to have three images, and perhaps a fourth image placed under a file controller. Bruno, Olivier and Annie work each on its private image and don't change the write accesses, except to loose the write access, or to get the write access to a protected package(s) not own by the others since the last synchronization.
Sometimes, for instance because Annie define a class used by Olivier, you have to synchronize the parallel developments. In this case using File Synchro, Annie Olivier and may be Bruno get the modifications done by the others. When the project is synchronized it is also possible to change the write access from a user to an other one, obviously this must be made on all the images, or on one image and copying it in the others.
Obviously like in any development, when an element is removed from the model by Bruno, for instance a class, he has to ask for Olivier and Annie except if this element was not yet delivered to them. To move an element inside the browser is not a problem, an element is referenced through an internal key, not through its location. In a similar way an element may be renamed because the key doesn't contains the name, but this may have impact in the body of the operations where the renaming is not taken into account by BOUML itself.
Previous : Project synchro
Next : Project files