Modélisation UML & SysML

Je me suis rendu le 15 mai à la première édition de l’EAUG (Enterprise Architect User Group) où s’est réunie à Londres la communauté des utilisateurs d’Enterprise Architect.

Vous trouverez dans cet article la synthèse d'une sélection de présentations auxquelles j’ai assisté :

1. "Modeling Software Intensive Systems" de Doug Rosenberg d'ICONIX, introduisant le concept de SwissML (SysML + UML) pour obtenir le même niveau de spécifications sur les blocs logiciels et matériels d'un système embarqué. Doug aborde l'incompatibilité des méthodes agiles dans un contexte où le logiciel n'est pas le livrable final, mais fait partie d'un système comprenant un ensemble de blocs matériels et logiciels, avec une forte criticité sur les erreurs possibles en raison des risques liés à la sureté et à la sécurité.
2. "SysML with EA" de Roman Bretz de Lieber Lieber GmbH nous faisant part de ses retours d'expérience en clientèle sur le langage de modélisation SysML.
3. "User Story : EA usage at EVRY" de Knut Paulsen d'EVRY, qui nous a présenté l'utilisation d'EA dans la société EVRY, impliquant notamment la réalisation d'Add'Ins EA (générateur de documentation, export/import Excel) définis selon la méthodologie adoptée en interne.
4. "User Story: How to do less work, have more fun and become (a bit) famous doing it" d'Ian Mitchell d'Ability Engineering, qui nous a fait part de ses retours d'expérience en tant que BA au sein d'un projet d'envergure à l'échelle européenne. Des conseils et avis très intéressants et pertinents !

SWISSML, l’union de SYSML et UML (et non un langage de modélisation helvétique), ou la nécessité de soumettre la réalisation du logiciel aux exigences et modèles du système

La présentation « Modeling software engineering systems » de Doug Rosenberg d’ICONIX aborde le rôle critique des spécifications pour les logiciels de type système embarqué. Dans un contexte d’ingénierie système, où une erreur logicielle peut non seulement comporter des impacts économiques, mais surtout des risques liés à la sureté et à la sécurité, la réalisation de la partie logicielle du système ne devrait pas être effectuée séparément des spécifications. Or c’est souvent le cas, notamment lorsque la réalisation est déléguée à une équipe SCRUM.

Pour illustrer ce point, Doug a cité un exemple vécu en tant que client de la compagnie aérienne American Airlines (AA), où il a obtenu une date décalée d’un mois sur son billet. Ce bug du système de réservation était connu d’AA. Une simple recherche google a permis de montrer que des logiciels pour AA ont été réalisés dans un cadre agile, ce qui est peut-être le cas pour ce système de réservation de billets.

Doug nous a ensuite rappelé quelques principes agiles et techniques de développement logiciel :

• Le TDD privilégie les tests, le refactoring et la correction du code.
• L’application du manifeste agile concernant la documentation (« Working software over comprehensive documentation ») donne lieu à un niveau de spécifications (user stories) peu détaillé.

Ces approches, selon lui, ne sont pas compatibles avec les projets d’ingénierie système, où l’on a besoin de spécifications très détaillées, et où l’on préconise de simuler le modèle pour le valider avant de développer, notamment grâce aux outils SysML ou autres (ex : MatLab).

Ces choix augmenteraient donc les risques de bugs critiques. Dans l’exemple donné, l’on pourrait imaginer les problèmes associés au bug du logiciel de réservation de billets si les données de ce système sont utilisées par un système de gestion du poids des bagages chargés dans l’avion.

Pour Doug la réalisation d'un système embarqué selon une approche agile nécessite des spécifications utilisant la modélisation. Il a défini pour cela l’approche SwissML (UML + SysML).

Doug nous présente alors les modèles et piliers de SysML pour la partie système :

• Modèle d’exigences
• Modèle du domaine pour définir le vocabulaire métier
• Les aspects structurels : block definition diagrams à 2 niveaux (sub-system puis component), et les internal block diagrams pour le plus fin niveau de granularité
• Les aspects dynamiques : cas d'utilisations, diagrammes de séquence (conception), diagrammes d’activité pour les scénarios de cas d'utilisations, et les state machines.

Le principe de SwissML est d’obtenir le même niveau de spécifications sur les blocs matériels (par exemple un système embarqué pour un System On Chip) que sur les blocs logiciels. On peut ainsi définir dans le même projet EA les modèles SysML du système avec les modèles UML de la partie logicielle. Ainsi le logiciel peut répondre aux exigences du système, et avoir un niveau approprié (élevé) de spécifications.

Remarque : il est important de préciser dans ce talk que les méthodes agiles ne sont pas remises en question pour des réalisations logicielles, mais que celles-ci ne sont pas compatibles telles quelles pour un contexte en ingénierie système.

SYSML WITH EA

Roman Bretz de Lieber Lieber GmbH (Autriche) nous a fait part de ses retours d’expérience avec SysML.

Plusieurs rappels sur l’intérêt d’utiliser un langage de modélisation ont été donnés ; « un langage est un support de communication qui doit être compris par tous ».

Roman nous indique que la plupart des projets utilisent surtout les modèles d’exigences et d’architecture (BDD, IBD), et peu de projets utilisent les diagrammes dynamiques (activité, state machine, use case).

En prenant l’exemple d’un système « thermomètre », Roman nous présente chaque modèle SysML :

• Modèle d’exigences, et traçabilité avec les modèles d’architecture et dynamiques
• Analyse des cas d’utilisations du système
• Roman nous précise que c’est un aspect déterminant du modèle, où la priorité est donnée sur les résultats et l’enchainement des actions pour chaque cas d’utilisation.
• Ce modèle détermine également le périmètre du système.
• Roman nous fait un retour intéressant : un client ne souhaitait pas un modèle de cas d’utilisation ne le jugeant pas nécessaire et trop couteux. Or après avoir fait l’exercice d’identifier tous les cas d’utilisations, les participants ont obtenu plus de 300 cas d’utilisations, ce qui a permis d’indiquer qu’ils ne maitrisaient pas le périmètre de ce système. Ils sont ensuite arrivés à définir une dizaine de cas d’utilisations, et les bénéfices de cette démarche ont donc été visibles.
• Contexte du système : représenter ce qui est en interaction avec le système
• Modèle du domaine : permet d’établir un pont entre les termes métiers et les modèles SysML.
• Modèle dynamique
• Le comportement des blocs d’un système va au-delà des attributs et signatures d’opérations. En effet un bloc peut être relié via l’allocation (traçabilité en termes systèmes) à des activités, interactions (ex diagrammes de séquence), et machines à états.
• Les activités et interactions correspondent à une partie de l’implémentation d’une opération du bloc, alors que les machines à états représentent le cycle de vie du bloc.
• L’on voit alors qu’il peut être utile dans EA, via une manipulation manuelle, de représenter des compartiments supplémentaires dans un bloc, illustré ci-dessous :

Utilisation d’EA chez EVRY

Knut Paulsen a partagé son expérience et utilisation avancée d’EA dans l’entreprise EVRY, basée en Norvège.

Profile UML

EVRY a défini un profile UML pour enrichir leurs modèles de cas d’utilisation selon les préconisations du livre d’Alistair Cockburn :

• De nouvelles propriétés ont été rajoutées aux ‘use case’ (accessibles via les tagged values), et deux nouveaux types de use case ont été définis : summary & user goal
• Des classes stéréotypées ‘Field List’ (selon Cockburn) ont été définies pour être associées aux use case. Ainsi il est possible d’associer un use case par exemple « rechercher un compte client » avec une liste de champs. Ce concept est intéressant car tout en restant au niveau de l’analyse, on agrémente ce modèle en identifiant les champs qui seront nécessaires à la réalisation d’une IHM en conception.

Création d’Add’ins EA pour répondre aux besoins d’EVRY

Knut et son équipe ont réalisé deux add’ins en utilisant l’API d’EA :

1- Un export/import Excel avancé a permis à EVRY d’envoyer des listes d’exigences à leurs différents interlocuteurs, afin que ceux-ci puissent aisément les mettre à jour sous Excel, puis les mettre à jour dans EA via un import. Les fonctions d’import/export CSV d’EA sont limitées et fastidieuses, aussi cet Add’In a grandement simplifié les taches de mises à jour des exigences, car il est plus facile de maintenir les exigences via des classeurs Excel plutôt que directement sous EA.

2- Le générateur RTF d’EA étant très limité, EVRY a développé son propre générateur de documentation Word avec des fonctionnalités avancées qui répondent à leur méthodologie interne :

• Tracer la date et le nom de la personne qui a approuvé une version d’un cas d’utilisation;
• enregistrer une nouvelle version du document Word pour un use case dans un répertoire partagé configurable;
• une gestion simple et complète sur les numéros et autres attributs pour chaque révision du document.

La complexité et les bénéfices de ces add’ins montrent un réel investissement d’EVRY pour adapter l’outil EA à la méthodologie adoptée par les équipes.
Ces outils ne sont pas accessibles au public, aussi cette présentation a été très intéressante pour savoir ce que l’on peut faire moyennant les efforts de réalisation nécessaires.

EA pour une seule version de la vérité, et produire des documents à granularités différentes pour faciliter l’accord de chaque responsable

Ian Mitchell d’AbilityEngineering nous a présenté ses retours d’expérience sur un projet d’envergure à l’échelle européenne.

Ian a rejoint ce projet en tant que BA pour résoudre les difficultés à gérer et organiser un nombre très important de demandes. En effet une première version du produit avait été mise en production, ce qui avait suscité énormément de demandes pour la version suivante du système. De plus, ces demandes étaient exprimées par les responsables produits de chaque pays, chacun avec ses propres contraintes locales.

Ian a alors démarré un référentiel EA comprenant entre autre :

• Des ‘features’ exprimées par les clients,
• un modèle d’exigences associées aux ‘features’,
• un ‘domain model’ pour comprendre les entités métiers et ainsi définir le vocabulaire,
• et un suivi des risques, actions, évolutions, et problèmes via des éléments stéréotypés : risks, actions, changes, issues. Par exemple, les actions identifiées lors de réunions étaient créées dans EA et pouvaient par la suite être associées avec une liste d’éléments de type ‘change’.

EA est devenu le référentiel des connaissances et définitions du système pour une vision unique de la "vérité", ce afin d’éviter la recherche d'informations parmi des documents ou wiki externes.  Ian nous fait part d’un conseil très pertinent : plutôt que d’essayer de tout redéfinir sous EA, le BA doit passer un certain temps à réunir et collecter l’existant - documents, standards, schémas visio et autres - puis les réunir dans EA afin que ce référentiel soit riche et complet dès le départ. Cela permet ainsi d’associer une nouvelle règle métier avec un document standard pour justifier à tout moment son existence, évitant plus tard de supprimer cette règle ne sachant plus dans quel cadre celle-ci a été définie.

A l’issue de la phase d’analyse pour la version suivante du système, le document de spécifications a été généré pour obtenir l’accord de chaque responsable produit. Or comme beaucoup d’éléments étaient spécifiques à un seul pays, plusieurs responsables étaient retissant à donner leur accord sur un document où une grande partie du contenu ne les concernaient pas.

Ian a donc identifié avec chaque responsable ce dont il attendait du système. Ces liens ont été répercutés sous EA par la création d’acteurs stéréotypés ‘stakeholder’ et associés à l’ensemble des éléments pertinents. Cette traçabilité a permis de générer un document de spécifications pour chaque responsable avec un contenu d’exigences, règles métiers, et cas d’utilisations approprié. Le générateur de documents RTF sous EA étant trop limité, Ian a utilisé le générateur de documentation EADocX, créé et commercialisé par son entreprise.

En conclusion :

• Ian nous rappelle que peu importe la richesse et structure du projet EA mis en place, la qualité du travail réalisé se voit par le contenu des documents livrés. Il est donc primordial de générer les informations pertinentes.
• Le référentiel EA est devenu un asset central au projet, aussi le client a mis en place une équipe en interne dédiée au maintien de ce projet EA.

Conclusion

Une réussite pour ce premier EAUG en Europe avec des retours d’expériences très enrichissants, et des échanges avec les speakers et membres de la communauté Enterprise Architect.
Pour plus d’informations : www.eausergroup.com.