Cet article est la seconde partie de mes retours sur la journée de présentations à l'EAUG Londres 2017 qui s'est déroulée Vendredi 19 Mai (la première partie sur la journée de formations est disponible ici). Il permet d'illustrer la qualité d'information délivrée pour les utilisateurs EA n'ayant pas eu la possibilité de se joindre à l'EA User Group de cette année.
Le planning ci-dessous proposait de suivre la keynote et 5 présentations avec un choix parmi 3 sujets pour chaque session.
Un résumé d'une partie des présentations suivies est proposé ci-dessous. J'aborde également ma présentation sur eaTests, une solution de tests automatiques pour les add-ins et scripts EA.
Keynote : l'innovation a besoin de modèles (Innovation Needs Models)
La keynote de cette année a été animée par Peter Lieber (Sparx Systems Central Europe, Autriche).
Peter nous a partagé son expérience et ses recommandations sur l'introduction de l'approche de modélisation pour un projet ou une entreprise :
- Tout d'abord un langage de modélisation et un outil doivent être sélectionnés (ex : SysML + EA). Une méthodologie est également nécessaire pour poser une structure, un cadre, des processus. Enfin la présence et l'enrichissement continu d'une expérience doivent être pris en compte.
- Remarques
- Il important de préciser qu'un outil de modélisation comme EA avec un langage tel que SysML ne sont pas suffisant pour établir une approche de modélisation; une méthodologie est nécessaire et doit être définie selon chaque contexte ou projet en l'absence de standards ou de règles à ce sujet.
- Un outil comme EA est nécessaire pour être productif.
- Peter a fait un retour sur des scénarios qui ont réussis ou échoués :
- Une expérience réussie en modélisation nécessite une construction itérative avec des objectifs atteignables par l'équipe.
- Un exemple de scénario qui a échoué a été illustré dans un contexte avec une seule cible complexe. Ce choix a entraîné un arrêt progressif des actions après avoir atteint la cible, faute d'adhésion de l'équipe.
- Un autre exemple d'échec est lié au cas où une entreprise choisit de tout utiliser, par exemple tous les diagrammes UML. Les budgets et l'implication des utilisateurs sont intégralement consommés avant d'obtenir un résultat visible, illustrant l'intérêt de modéliser.
La présentation s'est alors orientée sur des systèmes avec un fort aspect de sécurité, sureté, et complexité tels que des trains, véhicules routiers, et avions. La sécurité est souvent soumise aux normes et standards comme avant l'ISO-26262 (Road Vehicles Functional Safety). Selon les challenges posés par ce standard, seule l'approche par les modèles est considérée comme une option viable; la modélisation permet de gérer des éléments (ex : exigences, blocs) et diagrammes qui sont tous connectés via la traçabilité, identifiée comme intelligence des modèles.
Avec l'outil Sparx Enterprise Architect pour gérer la traçabilité, une méthodologie doit être définie pour identifier les processus de mise à jour des modèles, les diagrammes à utiliser et pour quel besoin, l'emplacement des éléments et diagrammes dans le référentiel de modélisation...
Pour faciliter l'adoption par les ingénieurs système, le langage utilisé (UML, SysML) peut être adapté au contexte via des stéréotypes dans un profil UML. Les niveaux ASIL (Automotive Safety Integrity Level) de l'ISO 26262 peuvent être réalisés dans les blocs du système au travers d'une palette de couleurs associée. Lorsque les diagrammes ne sont pas toujours appropriés pour partager des informations, celles-ci peuvent être extraites au format Excel (matrice de décision).
La présentation s'est terminée sur le concept d'utiliser Enterprise Architect comme plateforme intégrant :
- des liens avec d'autres outils comme IBM DOORS pour la synchronisation d'exigences;
- des profils UML et boîtes à outils personnalisées;
- des scripts d'automatisation;
- l'exécution de simulations;
- la validation des modèles;
- la publication de modèles via la fonction Reusable Assets Service;
- la génération documentaire.
Solution de tests automatiques pour les add-ins et scripts Enterprise Architect
Ma présentation cette année s'est portée sur une solution de tests automatiques pour les add-ins et scripts EA réalisée dans le cadre d'un projet personnel récent.
Depuis 2015, je partage gratuitement eaUtils, un add-in utilitaire pour EA (www.eautils.com). eaUtils propose diverses fonctionnalités qui permettent d'améliorer l'utilisation quotidienne d'EA dans certains cas comme le tri d'éléments dans les modèles, ou la génération de références sur l'alias d'éléments (ex : exigences) selon leur ordre d'affichage dans un diagramme.
Les améliorations réalisées au fur et à mesure du projet, notamment issues de retours utilisateurs, ont donné lieu à un niveau élevé de complexité. En tant qu'add-in gratuit, il reste nécessaire de maintenir un niveau minimum de qualité et de tests afin d'être utile pour la communauté Sparx. Avec un temps personnel limité pour réaliser des tests manuels, j'ai investigué une solution de tests automatiques avec les objectifs suivants:
- Réduire radicalement le temps nécessaire aux tests.
- Définir et exécuter les tests dans EA.
- Passer du temps à améliorer les tests plutôt que de les exécuter.
L'analyse de la structure des tests a donné lieu au diagramme de classe suivant :
En phase de conception, la réalisation d'un modèle XML Schema a permis de générer un fichier XSD depuis EA. Ce fichier était nécessaire pour structurer les fichiers XML qui contiennent la description des tests. Une première version fonctionnelle de tests automatiques a permis de dérouler la procédure suivante :
- Mettre à jour la configuration (settings) et lancer une fonction de l'add-in pour générer les données de tests d'une nouvelle étape. Cette fonctionnalité évite la saisie manuelle des données dans le fichier XML, conformément au premier objectif.
- Activer le module de tests automatiques en tant que développeur de l'addin eaUtils, puis lancer son exécution sur un projet EA de tests.
- Parcourir les résultats au travers des diagrammes de séquence générés.
- Corriger les anomalies pour un test en échec et relancer la procédure.
L'illustration ci-dessous présente :
- la structure du projet EA de test avec les jeux de données (data set) et les éléments "étape de test" (test steps);
- la procédure d'exécution des tests automatiques (extraction et conversion des données du fichier XML, puis traitement de chaque étape avec mise à jour de la configuration, appel de la méthode avec paramètres présents, vérification des post conditions, et génération des résultats).
Exemple de diagramme de séquence généré avec les résultats d'une étape de tests :
Lors de la première partie de ma démonstration, j'ai exécuté les tests automatiques sur l'add-in eaUtils (avec un effet démo limité à un verre d'eau renversé sur la table, hors de portée de mon PC portable. Heureusement aucun soucis technique!).
La présentation s'est ensuite portée sur l'idée de rendre ce module utilisable par d'autres add-ins ou scripts. Il existe en effet de nombreux scripts et add-ins réalisés pour EA, la grande majorité étant je pense spécifiques à un client ou projet (donc privés). Le reste des scripts et add-ins sont partagés en tant qu'outils Open Source, gratuits, ou commerciaux. A noter que Sparx Systems maintient une liste officielle sur le lien suivant : third party extensions page.
La démarche d'intégration a débutée par l'identification de candidats :
- hoTools, un projet Open Source géré par Helmut Ortmann. La disponibilité d'un projet Open Source était primordiale pour accéder au code source et intégrer les fonctions de tests.
- EA scripting library publiée par Geert Bellekens.
- Une sélection parmi les scripts réalisés en clientèle : Lock Package et Teiid virtual DB schema DDL import.
Cette démarche s'est poursuivie avec les étapes suivantes:
- Extraction d'une librairie générique à partir d'eaUtils dans un nouveau projet C# : eaTests.
- Mise à jour de l'add-in eaUtils pour intégrer eaTests.
- Intégration d'eaTests dans l'add-in open source hoTools.
- Réalisation d'un nouvel add-in pour le test de scripts.
A l'issue d'une intégration réussie, j'ai été en mesure dans la deuxième partie de ma démonstration de présenter des tests automatiques sur une fonction de l'add-in hoTools (cf. présentation ici), un script de Geert, et mes 2 scripts.
Ce projet personnel a donné lieu à eaTests dont un site dédié est désormais disponible : www.eatests.com. Les prochaines évolutions consistent à intégrer en priorité de nouveaux types de tests sur les post conditions (ex : nom attribut dans une classe).
Les slides de la présentation sont disponibles en téléchargement ici.
Remplacer les solutions existantes avec Enterprise Architect, réaliser des fonctions complémentaires avec les MDG
Graham Williamson travaille chez Interserve, une société BTP comptant 85000 salariés dans le monde. Graham nous a fait part de ses retours d'expérience sur la mise en place d'une cartographie avec Sparx EA, la personnalisation d'ArchiMate 3, et la validation de modèles avec EA.
L'objectif de son projet était de basculer les procédures de saisie sur papier vers des solutions numériques (digital construction). L'identification des services, emplacements, clients, procédures, applications, données et technologies existants ont rapidement identifié la nécessité d'un outil de modélisation. Après avoir testé un premier outil de modélisation, Interserve a finalement opté pour Sparx Enterprise Architect afin de disposer des propriétés suivantes :
- Définition d'un meta modèle personnalisé.
- Souplesse d'utilisation en termes de modélisation.
- Archimate 3.
- Profil UML et stéréotypes.
- Recherches personnalisées sur les modèles via des requêtes SQL.
- Générateur documentaire.
- Outils d'automatisation (scripts, add-ins, API).
- Faible coût de licence.
Graham a partagé le meta modèle via leur sélection des éléments et relations Archimate 3.0, suivi d'exemples de stéréotypes Archimate 3 Interserve pour gérer des propriétés spécifiques au projet (ex : catégorie pour les system software).
La fonction de validation des modèles disponible depuis la version 13 d'EA a été utilisée pour vérifier que les relations entre éléments sont cohérentes avec les règles en place.
- Etape 1 : configurer et définir les règles de validation (liste des relations valides). Afin de faciliter la définition des règles au format XML attendu par EA, un add-in a été créé pour gérer ces règles via une interface utilisateur adaptée.
- Etape 2 : lancer la validation sur le modèle sélectionné et parcourir les résultats.
Les éléments "plateaux Archimate" ont été utilisés afin de gérer différents états d'une architecture (définition originale de l'Open Group pour un Plateau Archimate : "A plateau represents a relatively stable state of the architecture that exists during a limited period of time").
Les relations ne pouvant pas être associées à un élément de type plateau Archimate, des recherches personnalisées (SQL) ont permis de produire le résultat attendu pour vérifier le contenu de chaque état de l'architecture i.e. Plateau.
Autres fonctions EA utilisées :
- Matrice de relations pour maintenir les liens entre éléments d'un plateau.
- Diagramme Roadmap pour le planning de transformation.
- Heatmap et autres graphiques.
- Traçabilité et fonction "insert related elements" sur un diagramme pour construire le "business capability model".
Utiliser Enterprise Architect et SysML pour le développement d'un système de moteur intégré à la roue (In-Wheel Motor System)
J'étais particulièrement intéressé par cette présentation étant actuellement impliqué sur un projet SysML/MBSE dans l'industrie automobile dans la cadre de conformités avec l'ISO-26262.
John Gladstone travaille pour Protean Electric Ltd, une entreprise spécialisée dans les systèmes de moteur intégré à la roue pour des véhicules électriques ou hybrides (in-wheel motor systems). Les besoins adressés dans ce contexte via les modèles SysML avec Enterprise Architect ont été abordés tout au long de cette présentation.
Contexte
Un diagramme BDD (block definition diagram) SysML a été présenté pour illustrer le contexte du projet.
- La norme ISO-26262 (Road vehicles – Functional safety) s'applique aux systèmes réalisés et nécessite l'identification de buts de sureté (safety goals).
- Des mécanismes de sureté doivent être définis au travers de modèles d'architecture et de conception pour assurer leur intégrité. Ces mécanismes doivent empêcher des dangers tels que l'accélération non intentionnelle du véhicule.
Comportement du système
Le comportement du système a été modélisé au travers de cas d'utilisation, dont les scénarios ont été détaillés avec des diagrammes de séquence. Afin de modéliser le comportement du système en cas de problème, l'équipe Protean a inventé un acteur baptisé "Gremlin".
Les diagrammes de séquence comportaient alors 2 acteurs, le conducteur et le gremlin, et le système ou véhicule électrique avec l'ensemble des interactions.
Besoins de modélisation
Un résumé des besoins de modélisation liés au système de moteur a été illustré via un diagramme BDD SysML :
- Un modèle architecture framework pour assurer une intégrité via la cohérence, complétude et justesse selon les besoins du standard ISO-26262.
- Le système est décrit au travers de son architecture, modélisée par des praticiens SysML qui utilisent le langage de modélisation SysML, une notation semi-formelle fortement recommandée par l'ISO-26262.
Comprendre SysML
John a partagé ses lectures pour comprendre SysML :
- SysML Distilled: A Brief Guide to the Systems Modeling Language from L.Delligatti
- SysML for Systems Engineering from Jon Holt and Simon Perry (Simon était présent à l'EAUG!)
- A practical guide to SysML from S.Friedenthal and A.Moore
Modèle Architecture Framework
- Ce modèle doit définir les différents points de vue ou viewpoints (perspectives).
- Il a été implémenté avec une MDG Technology qui comprend des stéréotypes SysML personnalisés dans un Profil UML, des boîtes à outils, et des recherches personnalisées.
- Il est complété dans le référentiel par un modèle de conception.
Processus et méthodologie
Le processus et la méthodologie à suivre ont été définis au travers de guides et diagrammes liés à chaque point de vue.
Modèle exemple
Afin de faciliter la compréhension et l'utilisation de l'environnement de modélisation avec les frameworks, procédures et méthodologie, un modèle d'exemple a été réalisé et diffusé auprès des équipes. Cet exercice utile s'est basé sur le système défini comme suit :
- Suffisamment complet pour comprendre et accéder à des cas pratiques conformes au framework et processus.
- Hors périmètre métier i.e. différent d'un moteur afin d'éviter toute discussion ou objection sur les détails du système.
- Utilise un sujet original : Protean a choisi comme système la navette spatiale Enterprise de la série Star Trek.
Conclusion
Derniers sujets abordés :
- La nécessité d'utiliser la fonction glossaire des termes pour s'assurer de l'utilisation correcte du vocabulaire lié au système ou au standard ISO.
- Générer les documents à partir des modèles.
- Une structure des modèles constituée d'une librairie d'éléments (ex : blocs, cas d'utilisations, exigences...) et de vues - perspectives.
Communauté d'utilisateurs Sparx EA
J'ai eu le plaisir de d'échanger avec de nombreux participants durant ces 2 jours.
Les travaux et questions autour d'EA étaient très intéressants, qu'ils s'appliquent dans un contexte d'analyse et de conception logicielle avec UML, d'ingénierie système avec SysML et MBSE, ou de cartographie et urbanisation avec UML ou ArchiMate.
Cet évènement m'a permis de retrouver ou rencontrer des utilisateurs que je connais via le forum Sparx ou par contact mail tout au long de l'année.
Les EA User Group ont pour objectif de permettre à une vaste communauté d'utilisateurs de se réunir avant de partir avec une richesse d'informations et d'éléments en complément des aspects de réseau.
Vivement le prochain EA User Group Londres 2018!