Plugin RhapsodySVN
Modélisation de Stakeholder Value Networks dans IBM Rhapsody
DE50 — Vincent Hilaire — UTBM
Hugo Charcot · Benjamin Groisne · Antoine Laurant · Arnaud Michel · Guillaume Retter
Table des matières
1. Introduction et contexte
Le problème, les sources et l'objectif du projet
Contexte : IBM Rhapsody et les SVN
IBM Rhapsody
- Environnement MBSE de référence industrielle
- Modélisation SysML / UML professionnelle
- Aucun support natif des Stakeholder Value Networks
Le problème actuel
- Calculs SVN effectués manuellement, hors outil
- Aucune mise à jour automatique lors d'une modification
- Risque d'erreurs et de perte de temps
Qu'est-ce qu'un SVN ?
Un Stakeholder Value Network est un graphe orienté pondéré modélisant les flux de valeur entre un système et ses parties prenantes.
Concept : Cameron (2007) | Application SysML : Sease et al., INCOSE 2018
Positionnement de la solution
| Critère | Sans plugin | Avec RhapsodySVN |
|---|---|---|
| Modélisation SVN | Outil externe, déconnecté | Natif dans Rhapsody |
| Calcul des scores | Manuel, source d'erreurs | Automatique (Cameron Eq. 2) |
| Mise à jour | Ressaisie complète | Dynamique (event-driven) |
| Visualisation | Aucune priorisation visuelle | Colorisation par rang automatique |
| Intégration modèle | Copie manuelle des résultats | Tag values dans le modèle SysML |
Objectif général du projet
Développer un plugin Java pour IBM Rhapsody 9.0 permettant de :
- Modéliser graphiquement un Stakeholder Value Network dans l'environnement Rhapsody natif
- Calculer automatiquement l'importance relative de chaque acteur (Cameron 2007)
- Propager les résultats dans le modèle SysML pour informer les choix d'architecture
2. Environnement, contexte et utilisateurs
Profil et contexte d'utilisation
Profil utilisateur cible
- Praticien de l'ingénierie systèmes utilisant Rhapsody au quotidien
- Concepteur ou analyste de systèmes complexes
- Aucune expertise SVN préalable requise
Phase d'utilisation
- Phase amont du projet : définition de l'architecture système
- Démarche MBSE où toutes les décisions s'appuient sur le modèle
- Avant la définition des exigences détaillées
Objectifs poursuivis par l'utilisateur
- Obtenir une vision structurée des relations de valeur entre acteurs et système
- Prioriser les orientations de conception de façon objective et quantifiée
- Détecter en amont les conflits potentiels entre fonctions ou exigences contradictoires
- Disposer de résultats directement intégrés dans le modèle SysML, sans ressaisie
Niveau de compétence requis
| Domaine | Niveau requis | Remarque |
|---|---|---|
| IBM Rhapsody | Intermédiaire | Navigation, diagrammes BDD/IBD |
| SysML | Intermédiaire | Blocs, stéréotypes, tag values |
| SVN / valeur perçue | Aucun prérequis | Pris en charge par le plugin |
| Développement / scripting | Non requis | Interface graphique uniquement |
3. Organisation du projet
- Méthodologie Agile
- 3 sprints de 3 semaines
- 14 avril au 16 juin 2026
Méthodologie Scrum
- 3 sprints de 3 semaines chacun
- Sprint planning + rétrospective encadrant chaque sprint
- Backlog fait sur Clickup
| Rôle | Élève |
|---|---|
| Product Owner | Guillaume Retter |
| Scrum Master | Arnaud Michel |
| Développeurs |
|
Diagramme de Gantt — Simplifié
14 avr
5 mai
26 mai
16 juin
Sprint 1
Sprint 2
Sprint 3
Bibliographie API
CdC + User Stories
Plugin Java
SVNProfile via Java
UC1 à UC4 (v1)
Cameron + DFS
Refacto (profil UI)
UC1-UC7 (profil UI)
Listener + Strategy
Rapport
Slides
Vidéo
Jalons : Conseil prof / Pivot architectural 25 mai · Rendu final 16 juin
Sprint 1
Sprint 2
Sprint 3
Tâche critique / refacto
Jalon
Sprint 1 — Exploration de l'API et premières tentatives
| Phase | Activité | Résultat |
|---|---|---|
| Semaines 1–2 | Recherche bibliographique, étude API Rhapsody, rédaction CdC et User Stories | Bases conceptuelles posées |
| Semaines 2–3 | Spike technique : Création du plugin entièrement via code Java | Limitations API identifiées — création de nouveaux types de diagrammes impossible depuis Java seul |
Sprint 2 — Première implémentation et pivot architectural
| Tâche | Description | Statut |
|---|---|---|
| SVNProfile (Java) | Création programmatique des stéréotypes, énumérations et tag values via l'API Java | Livré (v1) |
| UC1 — Config | Initialisation du profil SVN dans le projet courant | Livré (v1) |
| UC2 — Create Arc | Création d'un arc de valeur (IRPDependency) entre deux éléments | Livré (v1) |
| UC3 — Edit Arc | Édition BenefitRanking et SupplyImportance | Livré (v1) |
| UC4 — Calcul | Détection DFS des boucles de valeur + calcul | Livré (v1) |
| Conseil professeur | Retour en fin de sprint : créer le profil depuis l'interface Rhapsody, pas via Java — compatibilité et maintenabilité meilleures | Pivot décidé |
Sprint 3 — Refacto majeure, event-driven et livraison
| Tâche | Description | Statut |
|---|---|---|
| Refacto majeure | Suppression de la création programmatique du profil — intégration avec le profil créé depuis l'UI Rhapsody | Livré |
| UC1–UC5, UC7, UC8 | Réimplémentation sur la base du profil Rhapsody UI (stéréotypes, tag values, enums) | Livré |
| Listener | Architecture événementielle — recalcul automatique à chaque modification du modèle | Livré |
| Strategy pattern | ValueLoopStrategy (Cameron) + ArcSumStrategy (fallback sans nœud système) | Livré |
| Tests unitaires | Couverture model (Stakeholder, SVNSystem, ValueArc) + services de calcul | Livré |
| Livrables | Rapport, présentation, vidéo 3 min | Livré |
4. Objectifs du diagramme SVN
Les trois axes fonctionnels et la théorie sous-jacente
Trois axes fonctionnels
| Axe | Objectif | Résultat |
|---|---|---|
| 1. Modéliser | Représenter graphiquement les arcs de valeur entre acteurs et système | Graphe orienté pondéré intégré dans Rhapsody |
| 2. Quantifier | Calculer automatiquement l'importance relative de chaque acteur | Classement objectif (score 0–1) par stakeholder |
| 3. Informer | Propager les résultats dans le modèle système | Base quantitative pour les trade-offs d'architecture |
Matrice de scoring — INCOSE 2018
Score d'arc = BenefitRanking x SupplyImportance (Sease et al., INCOSE 2018, Figure 3)
| Supply \ Benefit | MIGHT_BE | SHOULD_BE | MUST_BE |
|---|---|---|---|
| LOW | 0.10 | 0.20 | 0.35 |
| MEDIUM | 0.20 | 0.35 | 0.65 |
| HIGH | 0.35 | 0.65 | 0.95 |
MIGHT_BE et LOW sont les valeurs par défaut des value arcs (0.10)
Algorithme de calcul — Cameron (2007)
Détection des boucles par DFS depuis le nœud system, puis calcul de l'importance :
Score d'une boucle L :
\[ \text{score}(L) = \prod_{i} \text{score}(\text{arc}_i) \quad \text{pour chaque arc de la boucle} \]
\[ \text{score}(L) = \prod_{i} \text{score}(\text{arc}_i) \quad \text{pour chaque arc de la boucle} \]
Importance d'un stakeholder S — Équation 2 (Cameron) :
\[ \text{importance}(S) = \frac{\sum_{L \ni S} \text{score}(L)}{\sum_{L} \text{score}(L)} \]
\[ \text{importance}(S) = \frac{\sum_{L \ni S} \text{score}(L)}{\sum_{L} \text{score}(L)} \]
- Résultat normalisé entre 0 et 1
- Si aucun nœud
system: stratégie de secours ArcSumStrategy (somme des arcs normalisée) - Écrit dans la tag value
importanceScorede chaque stakeholder
5. Fonctions du plugin
7 use cases implémentés — du cadrage à la visualisation
Les 7 Use Cases — Vue d'ensemble
| UC | Commande | Description | Priorité | Sprint |
|---|---|---|---|---|
| UC1 | SVN Configure |
Initialisation du SVNProfile (stéréotypes, enums, tag values) | MUST | S2 |
| UC2 | SVN Create Arc |
Création d'un arc de valeur (IRPDependency stéréotypée) | MUST | S2 |
| UC3 | SVN Edit Arc |
Édition BenefitRanking / SupplyImportance via dialogue Swing | MUST | S2 |
| UC | Commande | Description | Priorité | Sprint |
|---|---|---|---|---|
| UC4 | SVN Calculate |
Calcul scores Cameron — DFS + Équation 2 — mise à jour tag values | MUST | S2 | UC5 | SVN Colorize |
Colorisation automatique rouge / orange / jaune par rang | LOW | S3 |
| UC6 | SVN Update Arc Labels |
Affichage des scores de pondération comme étiquettes sur les arcs | MUST | S3 |
| UC7 | SVN Clean |
Suppression complète du profil SVN et réinitialisation du modèle | MUST | S3 |
Flux d'utilisation — De la configuration à la visualisation
UC1 est un préalable obligatoire — UC4 est déclenché automatiquement par le Listener (Sprint 3)
Architecture event-driven — La valeur clé
Avant Sprint 3
- Recalcul déclenché manuellement par l'utilisateur
- Risque d'oubli de mise à jour après modification
- Visualisation non synchronisée
Après Sprint 3 (Listener)
- Tout ajout / suppression / modification dans le modèle déclenche automatiquement le recalcul
- Colorisation et étiquettes mises à jour en temps réel
- Aucune action supplémentaire requise de l'utilisateur
6. Modélisation des éléments
Structure du profil SVNProfile, entités du modèle et attributs
Profil SVNProfile — Extension du modèle Rhapsody
| Élément | Type | Appliqué sur | Rôle |
|---|---|---|---|
«stakeholder» |
Stéréotype | Actor (IRPActor) | Partie prenante |
«system» |
Stéréotype | Class (IRPClass) | Nœud central |
«valueArc» |
Stéréotype | Dependency (IRPDependency) | Arc de valeur pondéré |
importanceScore |
Tag value | stakeholder | Score calculé |
benefitRanking |
Tag value (Enum) | valueArc | MIGHT_BE / SHOULD_BE / MUST_BE |
supplyImportance |
Tag value (Enum) | valueArc | LOW / MEDIUM / HIGH |
Diagramme de classes — Modèle de données SVN
Attributs de l'arc de valeur (IRPDependency)
| Attribut | Type | Description | Défaut |
|---|---|---|---|
benefitRanking |
BenefitRanking | Niveau de bénéfice attendu par le stakeholder | MIGHT_BE |
supplyImportance |
SupplyImportance | Importance de la fourniture du système | LOW |
score |
Float | Score calculé après exécution de UC4 | 0.10 |
| source | Stakeholder | SVNSystem | Nœud source de l'arc | — |
| target | Stakeholder | SVNSystem | Nœud cible de l'arc | — |
L'arc est modélé comme un IRPDependency dans Rhapsody — solution la plus compatible avec le profil BDD
7. Spécifications techniques et robustesse
Architecture, design patterns, stack technique et tests
Architecture d'exécution du plugin
Design patterns mis en œuvre
| Pattern | Classe principale | Rôle dans le plugin |
|---|---|---|
| Singleton | Logger |
Instance unique du logger ; accès uniforme depuis tous les composants |
| Strategy | ICalculationStrategy |
Interchangeabilité des algorithmes de calcul (ValueLoopStrategy / ArcSumStrategy) sans modifier le code appelant |
| Observer | Listener |
Souscription aux événements Rhapsody (afterAddElement, onElementsChanged) —
mise à jour automatique du modèle
|
Stack technique
| Composant | Choix |
|---|---|
| Langage | Java 8 (JDK 1.8) |
| Environnement cible | IBM Rhapsody 9.0 |
| OS supporté | Windows (DLL native) |
| Build | Maven 3.x |
| Livrable | JAR (plugin Rhapsody) + code source |
| API Rhapsody | rhapsody.jar (local) |
Extension du profil BDD
- Enrichissement des diagrammes BDD / IBD existants
- Nouveau type de diagramme étendant le profil BDD
- Compatibilité totale avec les modèles existants
Tests et robustesse
Couverture des tests unitaires
- Entités modèle :
Stakeholder,SVNSystem,ValueArc - Services de calcul :
ValueLoopStrategy,ArcSumStrategy - Cas limites : modèle vide, stakeholder isolé, graphe sans système
Gestion des erreurs
- Diagramme non-SVN : ignoré silencieusement par le Listener
- Profil absent : message d'erreur explicite à l'utilisateur
- Élément non sélectionné : commande annulée proprement
Difficultés rencontrées — Optimisation du Listener
Problème
- Le Listener déclenchait un recalcul complet pour chaque élément modifié
- Lors d'une opération groupée (ex. suppression multiple), Rhapsody appelait
onElementsChangeddes dizaines de fois consécutives - Résultat : crash de Rhapsody par surcharge des appels API
Solution
- Remplacement de la classe
SearchState(état mutable partagé) par une méthode récursive pure de recherche des value loops - Moins d'allocations mémoire, pile d'appels maîtrisée
- Le recalcul reste correct même si l'événement est reçu plusieurs fois
Merci pour votre attention
Questions ?
Hugo Chacrot · Benjamin Groisne · Antoine Laurant · Arnaud Michel · Guillaume Retter
DE50 — Encadrant : Vincent Hilaire · UTBM — P26