Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Follow the steps below to migrate your SysML model from Syndeia 3.2 to Syndeia 3.3. Do not install Syndeia 3.3 until specified in this process.

1. Create a backup copy of the following 2 files before you start this process.

  1. SysML model that you will be migrating
  2. repos.info file in the .syndeia folder in your home directory, e.g. C:\Users\Username\.syndeia\repos.info on Windows or /Users/Username/.syndeia/repos.info on Mac OS X.

If you make a mistake during this process, you will be able to copy the backup files and start this process again. 

2. Open the MagicDraw SysML model that was used/created with Syndeia 3.2, and launch the Syndeia Dashboard. Go to the Connection Search tab and press the Get All button. Note the number of connections. In this case, we will be demonstrating the migration process on a model with 140 connections. After migration to Syndeia 3.3, you will need to verify the number of connections.


3. Close the Syndeia Dashboard, SysML model, and the MagicDraw application.

4. Follow the installation instructions here to install Syndeia 3.3 plugin for MagicDraw. Note that you will need a new license file for Syndeia 3.3. 

5. After installation, start MagicDraw, right-click on any element in the Containment tree and select Syndeia → Settings.

6. Check that the setting Select primary store is set to SYSML_MODEL as shown below. If not, change to SYSML_MODEL and click on the Apply button.

7. Right-click You will see repositories being upgraded. Unique URLs kept.



6/ Connection search shows 0 connections. Do not close the Dashboard until connection upgrade is done.


7/ Connect to all your repositories. Very important, else connections will not be upgraded to 3.3.


8/ Upgrade to 3.3



Select to Upgrade Connections



5/ You will see upgrade of repositories and connections



6/ 

3/ 


Close Dashboard, save MD project, close, reopen, and check num connections, should see the same as above.






Users can upgrade Syndeia data created using Syndeia 3.1 to work with Syndeia 3.2. This Syndeia data primarily includes connections stored in SysML model and repositories stored in .syndeia folder. Follow the steps below to upgrade your models from Syndeia 3.1 to Syndeia 3.2.

(1) Open SysML project.

(2) Right click on any SysML element in the model tree and select Syndeia → Settings. Check that "Select primary store" is set to SYSML_MODEL.

(3) Launch Syndeia Dashboard - Right click on any SysML element in the model tree and select Syndeia → Dashboard. In the log window of the Syndeia Dashboard, you will see some stats. Syndeia will detect that the connections stored in the SysML model and repositories in the .syndeia folder are in an older format, and it will automatically upgrade connections to the 3.2 format. In this example, 173 connections were upgraded.

(4) Click on every repository listed in the Repository Manager to check that you can connect to it.

(5) Syndeia 3.2 needs more information from the connected models and repositories compared to Syndeia 3.1. Although all Syndeia information was upgraded to Syndeia 3.2 format (syntactic upgrade) in the previous step, we still to enrich that information. Right click on any element in the SysML model tree and select Syndeia → Utils → Upgrade Utils → Upgrade to 3.2, as shown below, to start the enrichment process..

(6) A new status dialog will pop up and show the running log as each connection is upgraded after fetching additional data from the connected models. After the process is over, you will see a summary of the upgrade in the Syndeia Dashboard, as shown below. The summary will show you the following stats:

  • Total number of connections
  • Number of connections that are upgraded, including connections that were already upgraded and those upgraded in this round
  • Number of connections that could not be upgraded

If the source / target end of the connection is missing, then the connection cannot be upgraded. For example, in the above scenario, 1 connection could not be upgraded because the target end of the connection is a local folder which is not available at the specified location. If that folder is made available at the specified location and the upgrade process is run again (next round), then the connection can be fully upgraded.

  • No labels