UML & SysML modelling languages

Sharing access to an Enterprise Architect modelling project can be achieved through a number of options such as using a central database server or coupling it with a version control repository (e.g. Subversion).

Using a central/shared database requires access to the DB server e.g. on a MySQL, Postgres, Oracle, or SQL Server DBMS.

This article illustrates a strategy and procedure to generate and work with an offline version, prior to merge and commit changes on the shared project when back online.

Context

The shared EA project I'm working is running on a Linux MySQL DBMS. EA Security has been enabled so users permissions and locks are managed and stored in the EA Project.

I recently had to run a workshop involving models review and live updates. I also had to update models offline whilst travelling. Hence I had to take an offline copy of the EA project that I could merge once back at the office.

Procedure

The procedure described in this section is split as follows:

• Create the offline copy
• Carry updates offline
• Apply updates from the offline copy back to the shared Enterprise Architect project

Offline copy

It is important to start by creating user locks on the packages that need to be updated offline.

Note that these locks mustn't be deleted so changes are not carried until modifications are merged into the central project, or locks released. This is important since EA Security doesn't prevent an admin user from deleting locks.

To create an offline local copy of the shared Enterprise Architect project, log in as an admin user and run the DBMS to EAP project transfert (EA menu Project > Data Management > Project Transfert). The resulting EAP file will be used to carry updates offline.

Carry updates

When working offline, e.g. during a workshop or whilst travelling, open and update models in the EAP file (packages, elements, diagrams...).

Upload modifications to the central EA project

Back at the office with an access to the DB server and ready to commit updates, the following process can be followed:

• Export the offline EAP file to an XMI file:
  • Open the offline EAP file in Sparx Enterprise Architect.
  • In the project browser, right click on the model root and select Export Model to XMI (alternative : right click on the package that includes all modifications and select Import/Export > Export Package to XMI file).
  • Make sure XMI 1.1 remains selected under Export Type as illustrated below, and click on Export. Once exported, click on Close, and close the EA project.

• Open the shared EA project via the ODBC connexion e.g. MySQL
• Make sure that all locks still exist.
• Right click on the model root > Package Control > Compare Package with XMI file, and select the XMI file generated from the offline EAP file (XML file).
• Enterprise Architect Baseline Comparison module starts and runs a full comparison between the offline export and the shared central EA project (this may take some time to run).
• Optional: in the baseline options, enable "Always Expand to Differences" 

• Alternative: collapse all packages, and right click on any package > Expand to Changed Items. This option may actually be faster after each package merge compared with the previous one.

• Under the first package or view below the model root to update, select all updated items to apply to the model : hold the shift + arrow down keys combination (or shift + page down) to select all updates to apply in the model.
• Right click on the selection and run Merge from Baseline (sometimes the option Add from Baseline is suggested instead).
  
  • If the following dialog prompt window is displayed, check that all models are locked.
    • Important: for some reasons, I had to remove all users' locks from the model and lock everything to my account to let the merge run without this prompt window. Removing all locks from other users is actually recommended to prevent any issue whilst running model merges.

• Enterprise Architect updates the model with changes carrried in the offline version. This process can take some time, around 10/15 minutes on average for medium sized packages.
  • Note 1: I initially had a concern about the order of the packages to run merges on, having possible relationships between elements from within those packages. Considering the following scenario: the model contains requirements that have a realization link from use cases located in a separate package. I ran some tests by merging packages in opposite orders e.g. requirements followed by use cases and vice versa.
    • Merging the Requirements package followed by the Use cases package was straightforward.
    • Merging the Use cases package first lead to outstanding relationships that could not be merged at this stage. Having run a merge on the Requirements, running it again on the Use Cases package enabled applying all changes to the main model (all outstanding relationships updates had been processed).
    • Finally, I ran an XMI comparison between both versions of EA projects; they were identical.
  • Note 2: diagrams keep showing as different in the Baseline Comparison even if they've been successfully merged. I found this is due to the time value of "00:00:00", whereas the baseline contains a proper time value set. I contacted Sparx Systems via the Report as a Bug form. For the time being, I just ignored this difference.

Other options

This procedure can somehow be cumbersome if model updates on the shared DB take a long time to process, and having several packages to merge.

As an alternative, an SVN repository can be set up and coupled with the shared DB project. When models need to be taken offline, each package can be configured with the Version Control repository prior to start an offline EAP copy of the shared EA project.