Why coArchi 2?

coArchi 1 and GRAFICO

coArchi version 1 began life in 2017 as a development of the GRAFICO project.

GRAFICO is a way to persist an Archi model as a collection of XML files (one file per Archi object or view). The resulting files can then be tracked and merged using standard Git operations. GRAFICO was extended and refined as part of coArchi version 1.

When an Archi model is saved it is saved in a single .archimate file (in XML format). However, in coArchi 1 the model is also saved as a collection of XML files just before an underlying Git operation such as a Commit is performed. Conversely, this collection of XML files is loaded and imported as an Archi model after each Git operation such as Pull, Merge, Checkout and so on.

Upsides of this approach

Having each model object as a separate XML file solves some of the problems related to Git operations using text files. Merging and finding the differences between versions of objects is less problematic, and an object's history can more easily be traced because the object consists of a small text file with its own individual history.

Downsides of this approach

However, there are downsides to this approach:

• Large Archi models can result in many thousands of small XML object files. Saving, loading and adding these files to the git index before a commit can be very slow. Some virus checkers can also slow down this process as each file is checked by the scanner.
• A lot of "tricks" are done to ensure that the Archi model stays in sync with these object files
• An error can occur when an object has been moved to a different folder or a merge is partially resolved leading to a corrupt model (See here and here).
• The object file's name prefix starts with the model object's type, for example BusinessActor_id1234.xml. It is now possible to change a concept's type in Archi and jArchi, and this file name is not updated.
• Every Archi new model feature has to be "hand-crafted" when supported in coArchi 1. For example, when the Specializations feature was added to Archi, it had to be manually added. Also, many new features such as icons, images, line width, line colour have been added to Archi and these do not appear in the merge conflict handler UI.

These are the main problems with coArchi 1, and there are other issues.

Realising the problems inherent in coArchi work began on coArchi 2 in 2020.

coArchi 2

coArchi 2 aims to resolve these problems by storing the Archi model in its native .archimate (single) file format (with images files stored in an images sub-folder), and by using EMF Compare to do the heavy lifting when merging and comparing models.

Upsides of this approach

• The model is saved and loaded using its native format, no need to convert to GRAFICO format. This is much, much faster than coArchi 1.
• All Git operations are faster because only a single file (and possibly a few image files) is checked when committing and merging
• EMF Compare allows us to show differences between versions of models
• EMF Compare allows us to merge models without errors or risks of model corruption
• Easier to maintain as new features are added to Archi. We don't need to add custom code to coArchi to support new features.
• Many improvements and new features have been added to coArchi 2

Downsides of this approach

• Because a model object is not saved as an individual XML file, as it was in coArchi 1, it is more difficult to trace the history of an individual object. This means loading the whole model for each commit in the history and, using EMF Compare, finding the object and comparing it with the previous version. This is slow and expensive.

Going forward

It has become difficult to maintain coArchi 1 and so we are moving forward with coArchi 2. coArchi 1 will still be available to download, but we won't be adding any new features.

There is still more work to be done on coArchi 2 and the first job is to achieve parity with the features of coArchi 1.

There are already some new user-facing features - folder groups in the Collaboration Workpace, compare model versions in the History view, allow to set and edit the remote repository location (no need to set this when creating the repository), and a nicer History view.

The immediate challenge is understanding and using EMF Compare to manage model versions and merging.