Physical organization
Introduction
This section presents the organization of the directories and files placed in the multi-user work space dedicated to teamwork.
Principle
The Objecteering teamwork MDACs are based on the internalization/externalization mechanism managed by Objecteering.
The externalization function is used to generate ASCII files which are representative of modeling elements (packages, classes, actors, etc) from the contents of an Objecteering project. Conversely, the internalization function is used to reread ASCII files, in order to update the information present in an Objecteering project.
In the suggested organization, each user has an Objecteering database in which a personal work project is defined. In this way, you work on your model in a private work space, while being able to reserve elements (check-out), deliver them (check-in) or quite simply update your personal model with regard to the multi-user model (Import, ...).
The multi-user model, which is made up of ASCII files, also allows the version and configuration management of modeling elements to a high level of precision (packages, classes, actors, use cases, …).

Figure 2. The multi-user work space
Directories
The directory which represents the repository is made up of several levels of information directly linked to MDAC possibilities:
· A directory for each type of multi-user atomic unit
· A "tmp" directory used to store temporary files used during optimization phases, present only with the Objecteering Multi-user teamwork MDAC
· A "Locks" directory containing locking files, used in the locking of elements or of the repository itself, and in the maintaining of its consistency.
· A "Deleted" directory, present only with the Objecteering Multi-user MDAC and containing elements explicitly destroyed in Objecteering Modeler. The files corresponding to destroyed elements are not deleted from the repository, but are only moved.
· A "log" directory containing each user's log file (username.log). The location and name of the log can be modified during MDAC configuration. For more information on MDAC parameterization, please see "Defining MDAC parameters".
· A "conf" directory, containing the repository configuration files.
Note: It should be noted that the file that manages information relative to model elements has a name that is internal to Objecteering (mainly constructed from element identifiers).
Access permission for directories
Repository users should have the following access rights described in the table below.
|
Directory |
Necessary
user rights |
|
Root directory |
Read access and directory creation |
|
Package, Class, Datatype, Item, Signal |
All rights |
|
Deleted |
All rights |
|
Locks |
All rights |
|
Log |
All rights |
|
Conf |
Read access only, all rights for repository administrator |
The location of Objecteering projects
We recommend that you create your databases on your machine's local disk, rather than a network disk, as teamwork operations, and the use of Objecteering itself, are much faster in this case. The Objecteering project is simply a view of the repository, which must be shared and regularly archived.
Databases should not be created on a network.
Using the externalization binary
The obj_extreport binary is used to find the list of the model's objects through an externalization hierarchy. To launch this binary, use the following syntax:
obj_extreport<CompleteExternalizationPath> [<TargetReportFileName>]
Example
Figure 3 below presents an example of objects listed in an externalization hierarchy.

Figure 3. Example of externalized objects in an externalization hierarchy