Modélisation UML & SysML

Le passage d'un projet de modélisation Enterprise Architect en mode collaboratif peut être réalisé de différentes façons, dont les principales options sont le stockage sur un serveur de base de données, ou la configuration d'un entrepôt de gestion de configuration SVN (d'autres serveurs de gestion de configuration peuvent être utilisés). Cette étape est nécessaire pour permettre à une équipe de travailler sur un référentiel EA partagé.
L'utilisation d'une base de données centralisée présente la contrainte d'avoir en permanence un accès au réseau pour être connecté avec le serveur utilisé, par exemple MySQL, Postgres, Oracle, ou SQL Server. Ce mode ne permet pas de travailler hors ligne.

Cet article partage une procédure que j'ai définie et utilisée pour travailler avec une version déconnectée du projet EA. Cette procédure se termine lorsque les modifications réalisées hors ligne sont appliquées sur le projet en base de données centralisée.

Contexte

Le contexte porte sur un projet Enterprise Architect stocké dans une base de données MySQL. La fonction "Security EA" a été activée et configurée pour définir les comptes utilisateurs, leurs permissions, et gérer les mécanismes de verrouillage.

J'ai été récemment en charge d'organiser un atelier sur site avec les experts métiers. Ne disposant pas d'un accès réseau durant cette réunion, j'avais non seulement besoin d'une version locale du projet, mais également de pouvoir réaliser des modifications pendant l'atelier, pour les appliquer dans le référentiel commun une fois de retour sur le réseau. Alors que la création d'une version locale est facilement réalisable via la fonction de transfert de projets EA, appliquer les modifications réalisées en mode déconnecté nécessite l'identification de règles et d'une procédure associée.

Procédure

La procédure proposée est composée des parties suivantes :

• Créer la copie locale.
• Réaliser des mises à jour hors ligne.
• Mettre à jour le projet partagé Enterprise Architect avec les modifications présentes dans la copie locale.

Copie locale

Avant de générer une copie locale dans un fichier EAP, commencer par créer les verrous utilisateurs dans la base centralisée sur les modèles qui doivent être modifiables hors ligne.

A noter que ces verrous ne doivent pas être supprimés avant d'avoir appliqué les modifications ou libéré les verrous. Ce point est important à souligner comme la fonction EA Security n'empêche pas aux administrateurs de supprimer des verrous utilisateurs en leur absence.

Pour créer une copie locale du référentiel Enterprise Architect partagé, s'authentifier avec un compte administrateur ou disposant des permissions nécessaires, et exécuter la fonction DBMS to EAP project transfert (menu EA Project > Data Management > Project Transfert). 

Réaliser des modifications en mode déconnecté (offline)

En mode déconnecté, par exemple durant un atelier ou lors d'un déplacement, ouvrir le fichier EAP généré précédemment pour mettre à jour les modèles (paquetages, éléments, diagrammes...).

Appliquer les modifications dans le projet EA centralisé

De retour au bureau avec un accès au serveur de base de données, suivre les étapes suivantes :

• Lancer un export XMI du fichier EAP "offline".
  • Ouvrir le fichier EAP dans Sparx Enterprise Architect.
  • Dans l'explorateur (project browser), lancer un clic droit sur la racine du projet et sélectionner Export Model to XMI (alternative: clic droit sur le paquetage modifié et sélectionner Import/Export > Export Package to XMI file).
  • L'option XMI 1.1 doit rester sélectionnée sous Export Type. Cliquer sur Export.
  • Fermer le projet EA.

• Ouvrir le projet EA centralisé via une connection ODBC (MySQL).
• S'assurer que tous les verrous existent bien.
• Lancer un clic droit sur la racine de modèle (model root) > Package Control > Compare Package with XMI file, et sélectionner le fichier XMI généré à partir du fichier EAP.
• Le module de comparaison Baseline Enterprise Architect s'ouvre et exécute une comparaison entre l'export du projet EA offline et le projet centralisé (cette étape peut prendre du temps à s'exécuter).
  • Optionnel : activer "Always Expand to Differences" dans les options baseline 

• Alternative : réduire tous les paquetages, lancer un clic droit sur l'un des paquetages > Expand to Changed Items. Cette option devrait être plus rapide que la précédente.

• Cliquer sur le premier paquetage à mettre à jour (ou sur le model root), puis sélectionner tous les éléments à fusionner avec le modèle : maintenir la touche shift appuyée et utiliser les flèches (ou shift + touche page down) pour sélectionner les modifications à appliquer sur le modèle.
• Lancer un clic droit sur la sélection et lancer la commande Merge from Baseline (l'option Add from Baseline est parfois proposée; l'utiliser dans ce cas).
  
  • Si la fenêtre de dialogue suivante est affichée, vérifier que tous les modèles soient bien verrouillés.
    • Important : dans mon cas j'ai été obligé en tant qu'administrateur de supprimer tous les verrous existants, puis de verrouiller tous les modèles sur mon compte utilisateur.

• Enterprise Architect met à jour les modèles avec le contenu de la version offline. Ce processus peut prendre du temps à s'exécuter, de l'ordre de 10 à 15 minutes pour des paquetages de taille moyenne.
  • Remarque 1 : j'ai étudié I'impact sur l'ordre des paquetages fusionnés lorsqu'il existe des associations entre éléments de ces paquetages. Exemple : un modèle contient des exigences avec des liens de réalisation depuis les cas d'utilisation présents dans un autre paquetage. J'ai effectué le test suivant : fusionner le paquetage Exigences suivi des Cas d'utilisations, et vice versa.
    • La fusion du paquetage des Exigences suivi des Cas d'utilisations s'est déroulée intégralement sans action supplémentaire.
    • La fusion du paquetage des Cas d'utilisations ne permet pas de traiter toute la liste; il reste des associations qui n'ont pas été fusionnées. Après avoir exécuté la fusion du paquetage des Exigences, une nouvelle exécution sur le paquetage des Cas d'utilisations a permis de traiter ces associations.
    • Pour vérification, une comparaison XMI entre le fichier XMI "offline" et un export XMI du projet EA centralisé a confirmé que les branches impactées sont identiques après fusion.
  • Remarque 2 : les diagrammes apparaissent dans la liste des éléments différents sous les résultats de comparaison Baseline après leur fusion. Cela est lié à l'heure de modification des diagrammes; leur valeur est fixée à "00:00:00" dans le modèle alors que la baseline (fichier XMI) contient une valeur appropriée (ex : 14:02:31). J'ai remonté ce point à Sparx Systems.

Autres options

Dans le cas où cette procédure ne se révèle pas adaptée en présence de lenteurs de mises à jour sur la base de données, ou d'un nombre élevé de paquetages à fusionner manuellement, une alternative avec SVN peut être mise en place. La présence d'un dépôt Subversion permet de configurer le paquetage à modifier "offline" avec la gestion de configuration SVN, et de modifier celui dans un fichier EAP, clone du projet EA centralisé.