Plugin RhapsodySVN
Modelisation de Stakeholder Value Networks dans IBM Rhapsody
DE50 — Vincent Hilaire — UTBM
Hugo Charcot · Benjamin Groisne · Antoine Laurant · Arnaud Michel · Guillaume Retter
Table des matieres
1. Introduction et contexte
Le probleme, les sources et l'objectif du projet
Contexte : IBM Rhapsody et les SVN
IBM Rhapsody
- Environnement MBSE de reference industrielle
- Modelisation SysML / UML professionnelle
- Aucun support natif des Stakeholder Value Networks
Le probleme actuel
- Calculs SVN effectues manuellement, hors outil
- Aucune mise a 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 oriente pondere modelisant les flux de valeur entre un systeme et ses parties prenantes.
Concept : Cameron (2007) | Application SysML : Sease et al., INCOSE 2018
Positionnement de la solution
| Critere | Sans plugin | Avec RhapsodySVN |
|---|---|---|
| Modelisation SVN | Outil externe, deconnecte | Natif dans Rhapsody |
| Calcul des scores | Manuel, source d'erreurs | Automatique (Cameron Eq. 2) |
| Mise a jour | Ressaisie complete | Dynamique (event-driven) |
| Visualisation | Aucune priorisation visuelle | Colorisation par rang automatique |
| Integration modele | Copie manuelle des resultats | Tag values dans le modele SysML |
Objectif general du projet
Developper un plugin Java pour IBM Rhapsody 9.0 permettant de :
- Modeliser graphiquement un Stakeholder Value Network dans l'environnement Rhapsody natif
- Calculer automatiquement l'importance relative de chaque acteur (Cameron 2007)
- Propager les resultats dans le modele SysML pour informer les choix d'architecture
2. Environnement, contexte et utilisateurs
Profil et contexte d'utilisation
Profil utilisateur cible
- Praticien de l'ingenierie systemes utilisant Rhapsody au quotidien
- Concepteur ou analyste de systemes complexes
- Aucune expertise SVN prealable requise
Phase d'utilisation
- Phase amont du projet : definition de l'architecture systeme
- Demarche MBSE ou toutes les decisions s'appuient sur le modele
- Avant la definition des exigences detaillees
Objectifs poursuivis par l'utilisateur
- Obtenir une vision structuree des relations de valeur entre acteurs et systeme
- Prioriser les orientations de conception de facon objective et quantifiee
- Detecter en amont les conflits potentiels entre fonctions ou exigences contradictoires
- Disposer de resultats directement integres dans le modele SysML, sans ressaisie
Niveau de competence requis
| Domaine | Niveau requis | Remarque |
|---|---|---|
| IBM Rhapsody | Intermediaire | Navigation, diagrammes BDD/IBD |
| SysML | Intermediaire | Blocs, stereotypes, tag values |
| SVN / valeur percue | Aucun prerequis | Pris en charge par le plugin |
| Developpement / scripting | Non requis | Interface graphique uniquement |
3. Organisation du projet
- Méthodologie Agile
- 3 sprints de 3 semaines
- 14 avril au 16 juin 2026
Methodologie Scrum
- 3 sprints de 3 semaines chacun
- Sprint planning + retrospective encadrant chaque sprint
- Backlog fait sur Clickup
| Eleve | Role |
|---|---|
| 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 a UC4 (v1)
Cameron + DFS
Refacto (profil UI)
UC1-UC7 (profil UI)
Listener + Strategy
Rapport
Slides
Video
Jalons : Conseil prof / Pivot architectural 25 mai · Rendu final 16 juin
Sprint 1
Sprint 2
Sprint 3
Tache critique / refacto
Jalon
Sprint 1 — Exploration de l'API et premieres tentatives
| Phase | Activite | Resultat |
|---|---|---|
| Semaines 1–2 | Recherche bibliographique, etude API Rhapsody, redaction CdC et User Stories | Bases conceptuelles posees |
| Semaines 2–3 | Spike technique : tentative de creation du plugin entierement via code Java | Limitations API identifiees — creation de nouveaux types de diagrammes impossible depuis Java seul |
Sprint 2 — Premiere implementation et pivot architectural
| Tache | Description | Statut |
|---|---|---|
| SVNProfile (Java) | Creation programmatique des stereotypes, enumerations et tag values via l'API Java | Livré (v1) |
| UC1 — Config | Initialisation du profil SVN dans le projet courant | Livré (v1) |
| UC2 — Create Arc | Creation d'un arc de valeur (IRPDependency) entre deux elements | Livré (v1) |
| UC3 — Edit Arc | Edition BenefitRanking et SupplyImportance | Livré (v1) |
| UC4 — Calcul | Detection DFS des boucles de valeur + calcul | Livré (v1) |
| Conseil professeur | Retour en fin de sprint : creer le profil depuis l'interface Rhapsody, pas via Java — compatibilite et maintenabilite meilleures | Pivot decide |
Sprint 3 — Refacto majeure, event-driven et livraison
| Tache | Description | Statut |
|---|---|---|
| Refacto majeure | Suppression de la creation programmatique du profil — integration avec le profil cree depuis l'UI Rhapsody | Livré |
| UC1–UC5, UC7, UC8 | Reimplementation sur la base du profil Rhapsody UI (stereotypes, tag values, enums) | Livré |
| Listener | Architecture evenementielle — recalcul automatique a chaque modification du modele | Livré |
| Strategy pattern | ValueLoopStrategy (Cameron) + ArcSumStrategy (fallback sans noeud systeme) | Livré |
| Tests unitaires | Couverture model (Stakeholder, SVNSystem, ValueArc) + services de calcul | Livré |
| Livrables | Rapport, presentation, video 3 min | Livré |
4. Objectifs du diagramme SVN
Les trois axes fonctionnels et la theorie sous-jacente
Trois axes fonctionnels
| Axe | Objectif | Resultat |
|---|---|---|
| 1. Modeliser | Representer graphiquement les arcs de valeur entre acteurs et systeme | Graphe oriente pondere integre dans Rhapsody |
| 2. Quantifier | Calculer automatiquement l'importance relative de chaque acteur | Classement objectif (score 0–1) par stakeholder |
| 3. Informer | Propager les resultats dans le modele systeme | 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éfaults des value arcs (0.10)
Algorithme de calcul — Cameron (2007)
Detection des boucles par DFS depuis le noeud 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 — Equation 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)} \]
- Resultat normalise entre 0 et 1
- Si aucun noeud
system: strategie de secours ArcSumStrategy (somme des arcs normalisee) - Ecrit dans la tag value
importanceScorede chaque stakeholder
5. Fonctions du plugin
7 use cases implementes — du cadrage a la visualisation
Les 7 Use Cases — Vue d'ensemble
| UC | Commande | Description | Priorite | Sprint |
|---|---|---|---|---|
| UC1 | SVN Configure |
Initialisation du SVNProfile (stereotypes, enums, tag values) | MUST | S2 |
| UC2 | SVN Create Arc |
Creation d'un arc de valeur (IRPDependency stereotypee) | MUST | S2 |
| UC3 | SVN Edit Arc |
Edition BenefitRanking / SupplyImportance via dialogue Swing | MUST | S2 |
| UC4 | SVN Calculate |
Calcul scores Cameron — DFS + Equation 2 — mise a jour tag values | MUST | S2 |
| UC5 | SVN Colorize |
Colorisation automatique rouge / orange / jaune par rang | MUST | S3 |
| UC7 | SVN Update Arc Labels |
Affichage des scores de ponderation comme etiquettes sur les arcs | SHOULD | S3 |
| UC8 | SVN Clean |
Suppression complete du profil SVN et reinitialisation du modele | MUST | S3 |
Flux d'utilisation — De la configuration a la visualisation
UC1 est un prealable obligatoire — UC4 est declenche automatiquement par le Listener (Sprint 3)
Architecture event-driven — La valeur cle
Avant Sprint 3
- Recalcul declenche manuellement par l'utilisateur
- Risque d'oubli de mise a jour apres modification
- Visualisation non synchronisee
Apres Sprint 3 (Listener)
- Tout ajout / suppression / modification dans le modele declenche automatiquement le recalcul
- Colorisation et etiquettes mises a jour en temps reel
- Aucune action supplementaire requise de l'utilisateur
6. Modelisation des elements
Structure du profil SVNProfile, entites du modele et attributs
Profil SVNProfile — Extension du modele Rhapsody
| Element SVNProfile | Type | Applique sur | Role |
|---|---|---|---|
«stakeholder» | Stereotype | Actor (IRPActor) | Identifie une partie prenante |
«system» | Stereotype | Class (IRPClass) | Noeud central du SVN |
«valueArc» | Stereotype | Dependency (IRPDependency) | Arc de valeur pondere |
importanceScore | Tag value (Float) | stakeholder | Score calcule — Cameron Eq.2 |
benefitRanking | Tag value (Enum) | valueArc | MIGHT_BE / SHOULD_BE / MUST_BE |
supplyImportance | Tag value (Enum) | valueArc | LOW / MEDIUM / HIGH |
Diagramme de classes — Modele de donnees SVN
Attributs de l'arc de valeur (IRPDependency)
| Attribut | Type | Description | Defaut |
|---|---|---|---|
benefitRanking | BenefitRanking | Niveau de benefice attendu par le stakeholder | MIGHT_BE |
supplyImportance | SupplyImportance | Importance de la fourniture du systeme | LOW |
score | Float | Score calcule apres execution de UC4 | 0.10 |
| source | Stakeholder | SVNSystem | Noeud source de l'arc | — |
| target | Stakeholder | SVNSystem | Noeud cible de l'arc | — |
L'arc est modele comme un IRPDependency dans Rhapsody — solution la plus compatible avec le profil BDD
7. Specifications techniques et robustesse
Architecture, design patterns, stack technique et tests
Architecture du plugin
Design patterns mis en oeuvre
| Pattern | Classe principale | Role dans le plugin |
|---|---|---|
| Singleton | Logger |
Instance unique du logger ; acces uniforme depuis tous les composants |
| Strategy | ICalculationStrategy |
Interchangeabilite des algorithmes de calcul (ValueLoopStrategy / ArcSumStrategy) sans modifier le code appelant |
| Observer | Listener |
Souscription aux evenements Rhapsody (afterAddElement, onElementsChanged) — mise a jour automatique du modele |
Stack technique
| Composant | Choix |
|---|---|
| Langage | Java 8 (JDK 1.8) |
| Environnement cible | IBM Rhapsody 9.0 |
| OS supporte | 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
- Compatibilite totale avec les modeles existants
Tests et robustesse
Couverture des tests unitaires
- Entites modele :
Stakeholder,SVNSystem,ValueArc - Services de calcul :
ValueLoopStrategy,ArcSumStrategy - Cas limites : modele vide, stakeholder isole, graphe sans systeme
Gestion des erreurs
- Aucun
NullPointerExceptionnon gere ne remonte a Rhapsody - Diagramme non-SVN : ignore silencieusement par le Listener
- Profil absent : message d'erreur explicite a l'utilisateur
- Element non selectionne : commande annulee proprement
Merci pour votre attention
Questions ?
Hugo Charcot · Benjamin Groisne · Antoine Laurant · Arnaud Michel · Guillaume Retter
DE50 — Encadrant : Vincent Hilaire · UTBM — P26