4.6 Évaluation
4.6.1 Évaluation de la méthodologie par rapport à un modèle manuel
4.1 Présentation
Dans le chapitre précédent, nous avons présenté notre approche qui introduit une nouvelle méthodologie de MBT pour le rendre plus accessible aux sociétés. Notre métho-dologie est composée de deux contributions :
— Enrichissement du modèle d’usage MaTeLo par la notion du context
— Un algorithme pour générer un modèle d’usage à partir d’un ensemble de diagrammes de séquences
Dans ce chapitre, nous présentons l’implémentation des fondements théoriques de notre méthodologie. Cela consiste à implémenter la notion du context nativement dans l’outil MaTeLo ainsi que le développement d’un nouvel outil, MUMG (MaTeLo Usage Mo-del Generator).
MUMG est un ensemble de plug-ins intégrés dans l’outil MaTeLo basé également sur la plateforme Eclipse RCP (Rich Client Platform). Cet outil permet de générer un modèle d’usage, compatible avec le modèle d’usage de MaTeLo, à partir d’un ensemble de dia-grammes de séquences. Ensuite ce modèle peut être importé dans l’outil MaTeLo afin de générer des cas de tests. Cet outil a été développé afin de permettre son application dans un contexte industriel.
Le projet Clarity [CS20], est un projet National de consortium d’industriels d’une du-rée de 3 ans (du Septembre 2014 à Septembre 2017). L’un des défis de ce projet était de créer un pont entre l’outil MBSE Capella [Cap20] et l’outil MBT MaTeLo, pour un MBT rentable et efficace. Ce défi soulève, entre autres, la question de recherche suivante pour l’intégration d’outils : Comment générer un modèle de test MaTeLo à partir d’un modèle de système Capella ?
Afin de répondre aux besoins de Clarity, nous avons effectué une deuxième implé-mentation de MUGM pour répondre aux exigences de ce projet.
4.2 Outils utilisés
Dans cette section nous présentons les outils utilisés pour l’implémentation de notre méthodologie.
4.2.1 Eclipse et Eclipse RCP
Eclipse est un projet ayant pour objectif de produire des logiciels libres et extensibles en se basant principalement sur le langage de programmation JAVA. Il a été créé en 2001 par IBM qui a fourni le code initial. Au début, la société IBM a créé un consortium com-posé de sept sociétés (dont Borland). Ensuite, la fondation Eclipse a remplacé ce
consor-tium afin de permettre l’entrée de nouveaux partenaires et de continuer ainsi à assurer le développement de la communauté Eclipse.
Le Framework Eclipse est un framework extensible basé sur la notion des modules appelé plug-ins.
Le noyau du framework Eclipse contient des mécanismes de découverte et de char-gement de plug-ins ainsi que la gestion du cycle de vie des plug-ins. Une nouvelle implé-mentation de ce noyau a été réalisée depuis la version 3.1 d’Eclipse sous la forme d’une implémentation de la spécification OSGi (spécification initialement créée pour le charge-ment d’applications Java sur des systèmes embarqués). L’IDE Eclipse ainsi que tous ses sous-projets sont également construis à partir d’un ensemble de plug-ins.
Le socle pour la création d’environnement de développement est implémenté dans le cadre du sous-projet nommé ’Eclipse Platform’. La version du socle ciblant le développe-ment d’applications installées sur les postes utilisateurs est nommée Eclipse RCP (Eclipse Rich Client Platform). La relation entre Eclipse RCP et Eclipse Platform peut se résumer de deux façons :
— Eclipse RCP est une version d’Eclipse Platform qui ne contient pas les modules cou-vrant les besoins propres aux environnements de développement.
— Eclipse Platform est une extension d’Eclipse RCP qui ajoute des fonctionnalités propres aux environnements de développement.
4.2.2 Eclipse EMF
Le projet EMF (Eclipse Modeling Framework) est un framework de modélisation, une infrastructure de génération de code et des applications basées sur des modèles de don-nées structurées appelés méta-modèle. Il a été lancé par IBM dans le but d’unifier les outils de développement développés par IBM utilisant des modèles basés sur EMOF. Avec la libération du code source de la plateforme Eclipse, IBM a donné à la fondation Eclipse le projet EMF.
Le projet EMF prend en entrée une spécification, décrite généralement sous la forme d’un modèle en XMI, appelé méta-modèle, et produit des classes Java représentant le mo-dèle avec un ensemble de classes pour adapter les éléments du momo-dèle afin de pouvoir les visualiser et les éditer.
4.2.3 Capella
Capella est un outil d’ingénierie système basé sur un modèle MBSE (Model Based Sys-tem Engineering). Il est basé sur la méthode Arcadia [VB13], qui est une méthode com-plète d’ingénierie basée sur des modèles et consacrée à l’ingénierie des systèmes, des logi-ciels et des architectures matérielles. En se référant aux trois piliers bien connus de MBSE
(langages de modélisation, outils de modélisation et processus basés sur des modèles), Arcadia/Capella fournit en outre le support pour le travail collaboratif sur la construction d’architecture. Ils guident les ingénieurs système à travers plusieurs niveaux de modélisa-tion : Analyse opéramodélisa-tionnelle, analyse de système (AS), architecture logique et architecture physique (AP) comme présenté dans la figure4.1.
FIGURE4.1 – Vue d’ensemble d’architectures Capella
Tout en se déplaçant à travers chaque niveau, les modèles sont développés avec des diagrammes différents, structurels et comportementaux. Capella fournit également plu-sieurs types de diagrammes comportementaux, tels que les diagrammes de machines à états ou de séquences. Par exemple, les diagrammes de séquences Capella réutilisent les notations et les conventions des diagrammes de séquences UML mais peuvent être ap-pliqués à d’autres domaines que UML.
Dans Capella, il existe trois types de diagrammes de séquences :
— Scénarios fonctionnels : Les lignes de vie sont des fonctions.
— Scénarios d’échange : Les lignes de vie sont des composants/acteurs tandis que les messages de séquences sont fonctionnels ou des échanges de composants.
— Scénarios d’interface : Les lignes de vie sont des composants/acteurs et les mes-sages de séquence sont des opérations d’interface).
De cette façon, selon le niveau de modélisation considéré, le modèle de conception per-met de vérifier le système en le considérant comme une boîte noire, une boîte grise ou un diagramme de séquences de boîte blanche.
Notre objectif est de générer un modèle d’usage, donc nous nous concentrons sur les scénarios d’échanges (Exchange scénarios). Un exemple de scénario d’échange dans une architecture logique est illustré dans la figure4.2.
FIGURE4.2 – Scénario d’exchange
4.2.4 Papyrus
Papyrus [Pap20] est un projet Eclipse qui vise à fournir un environnement intégré facile à utiliser pour éditer les modèles de type EMF (Eclipse Modeling Framework), il soutient en particulier UML et les langages de modélisation connexes tels que SysML et MARTE. Papyrus offre également un support très avancé pour les profils UML qui permet aux utilisateurs de définir des éditeurs pour les DSL (Domain Specific Language) basés sur le standard UML 2.
Nous utilisons Papyrus pour créer des diagrammes de séquences, et on utilise le for-mat de ces modèles dans l’implémentation de notre outil MUGM.
4.3 Implémentation MaTeLo
— L’implémentation de la notion du context dans l’outil MaTeLo
— L’implémentation de l’outil MUGM
4.3.1 Context
La première partie de l’implémentation de notre méthodologie est l’implémentation du context nativement dans l’outil MaTeLo. Notons que la notion du context dans Ma-TeLo est utilisée quotidiennement même pour la création des modèles manuels.
L’implémentation du context dans l’outil MaTeLo consiste à :
— L’implémentation d’une librairie des variables de contextes et l’implémentation d’une librairie pour les relations entre les variables de contextes (4.3.1.1)
— L’implémentation des transitions conditionnelles (4.3.1.2)
— La mise à jour des algorithmes de génération de MaTeLo afin de prendre en compte les variables de contextes, leurs relations et les transitions conditionnelles lors de la génération des cas de tests. Notons que cette partie est complexe surtout pour la mise à jour de certains algorithmes. Cette partie n’est pas décrite dans ce docu-ment car les algorithmes de l’outil MaTelo sont strictedocu-ment confidentiels.
4.3.1.1 Variables de contextes et relations
Nous avons créé une librairie racine pour les variables de contextes. Cette librairie contient deux librairies :
— Automatic Context Variables Library : Cette librairie permet la création des va-riables de contextes d’une façon automatique avec toutes les relations à partir d’une entrée. C’est un raccourci des variables de contexte qu’on peut créer manuellement avec toutes les combinaisons possibles
— Manual Context Variables Library : Cette librairie permet la création des variables de contextes d’une façon manuelle. L’utilisateur crée une variable de contexte en choisissant le type de cette variable, parmi les types "Numérique", "Boolean", "Chaine de caractère" et "Enuméré". Ensuite il saisit une valeur par défaut. En dessous de chaque variable, l’utilisateur pourra créer un ensemble de relations, où pour chaque relation il indique une valeur "source" de la variable de contexte, une valeur "desti-nation" de cette variable et la valeur de l’entrée (Input) qui permet de passer de la valeur "source" à la valeur "destination" (cf.4.8).
F IG U R E 4. 3 – Mét a-modèl e de la li b rair e d e s v ar iables de con text e
Ce méta-modèle est composé de :
— ContextVariablesLibrary représente la classe racine de ce méta-modèle. Elle est composée d’une instance de ManualContextVariablesLibrary et une instance de
AutomaticContextVariablesLibrary
— ManualContextVariablesLibrary représente la librairie de variable de contexte ma-nuelle. Elle est composée d’un ensemble de ManualContextVariable.
— ManualContextVariable est une interface implémentée par les classes
ManualE-numeratedContextVariable, ManualBooleanContextVariable, ManualTimeContext-Variable et ManualNumericalContextManualTimeContext-Variable qui représente respectivement des
variables de contextes manuelles de types Enuméré, Booléan, Temps et Numérique. Chacune de ces classes est composée d’un ensemble de Relation.
— Relation représente une relation d’une variable de contexte. Elle possède une va-leur active currentActiveClasse et une prochaine vava-leur nextActiveClass lorsque le système reçoit une valeur d’entrée précise InputToECMapEntry.
— AutomaticContextVariablesLibrary représente la librairie de variable de contexte automatique. Elle est composée d’une liste de InputToContextVariableMapEntry
— InputToContextVariableMapEntry est une association entre une entrée de système (Input) et une variable de contexte automatique AutomaticContextVariable .
— AutomaticContextVariable représente une variable de contexte automatique. Elle est composée d’un ensemble de Relation.
Notons que toutes les classes de ce méta-modèle héritent également d’une classe possé-dant un identifiant unique (uuid), un nom et une description.
La perspective "Edition", présentée dans la section2.5.1.3, de l’outil MaTeLo contient une vue appelée "Data". Nous avons ajouté dans cette vue une nouvelle librairie de don-nées appelée "Context Variables Library" 4.4qui représente la librairie des variables de contextes.
FIGURE4.4 – Libraire de variables de contexte
L’utilisateur peut créer une nouvelle variable de contexte en faisant un "click droit" sur le dossier Manual Context Variables Library et ensuite choisir le type de cette variable comme affiché dans la figure4.5.
FIGURE4.5 – Création d’une variable de contexte
Une fois que la variable est créée, elle peut être manipulée à partir de la vue Properties comme affiché dans la figure4.6.
FIGURE4.6 – Manipulation d’une variable de contexte
L’utilisateur peut créer une nouvelle relation d’une variable de contexte en faisant un "click droit" sur une variable de contexte et ensuite choisir le menu "New relation"4.7.
FIGURE4.7 – Création des relations des variables de contextes
Une fois que la relation est créée, elle peut être manipulée à partir de la vue Properties comme affiché dans la figure4.8.
FIGURE4.8 – Manipulation d’une relation d’une variable de contexte
4.3.1.2 Transition conditionnelle
Afin d’inclure les transitions conditionnelles dans les chaînes (diagramme états-transitions) de MaTeLo, nous avons créé un nouveau méta-modèle EMF pour la configuration des commutateurs. Ce méta-modèle est présenté dans la figure4.9:
Ce méta-modèle est composé de :
— Rule représente une règle. Elle est composée d’une instance de DefaultCondition et d’un ensemble de Condition
— DefaultCondition représente une condition "Else" d’un commutateur d’une tran-sition conditionnelle
— Condition représente une condition d’un commutateur, d’une transition condi-tionnelle, où chaque condition est composée d’un ensemble d’Evaluation.
— Evaluation représente une évaluation d’un commutateur d’une transition condi-tionnelle. Elle possède un opérateur (∈ ou ∉), une référence vers une variable de contexte et une référence vers une classe d’équivalence (valeur de cette variable de contexte).
Notons que toutes les classes de ce méta-modèle héritent d’une classe possédant un identifiant unique (uuid), un nom et une description.
Ensuite nous avons mis à jour le méta-modèle existant de MaTeLo, diagram. Cette mise à jour consistait à :
— Ajouter une nouvelle classe SwitchNode. Cette classe représente le commutateur et sa configuration d’une transition conditionnelle.
— Ajouter une classe Branch. Cette classe représente les branches d’une transition conditionnelle.
— Ensuite nous avons mis à jour la classe existante Diagram en ajoutant deux compo-sitions : Une pour la liste des SwitchNode et une pour la liste des Branch
F IG U R E 4. 10 – M éta -modèle des ch aines M aT eLo
L’utilisateur peut créer une nouvelle transition conditionnelle en utilisant un bouton dédié dans la barre d’outil de l’application MaTeLo.
Le nouvel objet transition conditionnelle dans le modèle d’usage MaTeLo est pré-senté dans la figure4.11.
FIGURE4.11 – Transition conditionnelle
Le commutateur est configurable à partir de la vue "Editor Properties" comme pré-senté dans la figure4.12.
FIGURE4.12 – Configuration du commutateur d’une transition conditionnelle
4.4 Implémentation du MUGM
La deuxième partie de notre implémentation est l’outil MUMG permettant de générer un modèle d’usage MaTeLo à partir d’un ensemble de diagrammes de séquences d’une façon semi-automatique avec des interventions mineures de l’utilisateur.
La version actuelle de l’outil MUMG est composée de plus de 8 000 lignes de code et vise à enrichir l’outil MaTeLo pour la génération automatique d’un modèle d’usage à partir d’un ensemble de diagrammes de séquences.
L’outil MUMG est composé de cinq plug-ins principaux : — com.all4tec.matelo.mumg.model — com.all4tec.matelo.mumg.parser — com.all4tec.matelo.mumg.importer — com.all4tec.matelo.mumg.converter — com.all4tec.matelo.mumg.importer.ui
4.4.1 Plugin : com.all4tec.matelo.mumg.model
Ce plug-in contient les données métiers de MUGM. Afin de rendre notre méthodolo-gie générique et indépendante de l’outil MaTeLo, nous avons créé un méta-modèle inter-médiaire Muprésenté dans la figure4.13. Ensuite nous avons généré le code à partir de ce méta-modèle.
La classe Diagram représente la classe racine de ce méta-modèle. Elle est composée de :
— Une instance de State appelée invokeState représentant l’état initial
— Une instance de State appelée terminateState représentant l’état final
— Un ensemble de MacroState représentant les états. Chaque MacroState possède une position x et y, un identifiant unique, un nom, une description ainsi qu’un en-semble de Transition entrantes vers cet état et un enen-semble de Transition sortantes de cet état
— Un ensemble de SwitchNode représentant les commutateurs des transitions condi-tionnelles. Chaque SwitchNode possède une position x et y, un identifiant unique, un nom, une description ainsi qu’une instance de Rule présenté dans4.9
— Un ensemble de Branch représentant les branches des transitions conditionnelles. Chaque Branch possède un identifiant unique, un nom, une description, un boo-léan indiquant si cette branche est une étape de test, ainsi qu’une instance
Switch-Node représentant l’état source de cette branche et une instance de State
représen-tant l’état destination de cette branche
— Un ensemble de Transition représentant les transitions. Chaque Transition pos-sède un identifiant unique, un nom, une description, un booléan indiquant si cette branche est une étape de test, ainsi qu’une instance de State représentant l’état source de cette transition et une instance de State représentant l’état destination de cette transition
F IG U R E 4. 13 – Méta -modèle de l’ap pli c ation M UMG
4.4.2 Plugin : com.all4tec.matelo.mumg.parser
Ce plug-in contient un parseur des diagrammes de séquences. Nous avons utilisé les diagrammes de séquences aux formats papyrus.
4.4.3 Plugin : com.all4tec.matelo.mumg.importer
Ce plug-in implémente la logique de notre algorithme pour générer un modèle d’usage au format Mu.
4.4.4 Plugin : com.all4tec.matelo.mumg.converter
Ce plug-in permet de transformer un modèle d’usage au format Mu en un modèle d’usage MaTeLo.
4.4.5 Plugin : com.all4tec.matelo.mumg.importer.ui
Ce plug-in offre la partie interface homme machine. Pour générer un modèle d’usage MaTeLo à partir d’un ensemble de diagrammes de séquences, nous avons ajouté un menu MUGM dans le gestionnaire de wizard de MaTeLo comme affiché dans la figure4.14.
FIGURE4.14 – Wizarde de MUGM
Lorsque l’utilisateur clique sur ce menu, une fenêtre "wizard" s’affiche permettant de choisir un fichier au format XML contenant les diagrammes de séquences à importer ainsi
que le nom du projet MaTeLo qui doit être créé. Ce wizard est présenté dans la figure
4.15. Lorsque l’utilisateur clique sur le bouton Finish de cette fenêtre, notre algorithme commence à s’exécuter.
FIGURE4.15 – Page de Wizard de génération d’un modèle d’usage
A la fin de la génération d’un modèle d’usage, et en cas de succès, nous aurons un nouveau projet dans MaTeLo contenant le modèle d’usage généré. En cas d’erreur, une fenêtre d’erreur s’affiche comme présenté dans la figure4.16
FIGURE4.16 – Erreur lors de la génération d’un modèle d’usage
4.5 Implémentation spécifique pour le projet Clarity
L’un des défis de projet National Clarity était de créer un pont entre l’outil MBSE Ca-pella [Cap20] et l’outil MBT MaTeLo. Pour répondre à ce besoin, nous avons implémenté un deuxième outil MUMGC (MaTeLo Usage Model Generator For Capella), qui est une version de MUMG adaptée pour Capella.
Il s’agit d’implémenter un ensemble de plug-ins à intégrer dans Capella pour générer un modèle d’usage MaTeLo à partir d’un ensemble de Exchange Scenario.
MUMG ( com.all4tec.matelo.mumg.model et com.all4tec.matelo.mumg.converter) et trois spécifiques : — com.all4tec.matelo.mumgc.capella.parser — com.all4tec.matelo.mumgc.capella.importer — com.all4tec.matelo.mumgc.capella.importer.ui
4.5.1 Plugin : com.all4tec.matelo.mumgc.capella.parser
Ce plug-in contient un parseur des Exchange scénarios Capella.4.5.2 Plugin : com.all4tec.matelo.mumgc.capella.importer
Ce plug-in implémente la logique de notre algorithme pour générer un modèle d’usage. Dans cette implémentation, pour chaque Exchange Scénario on génère une chaine Ma-TeLo. Donc la factorisation sera effectuée uniquement au niveau d’un Exchange Scénario.
4.5.3 Plugin : com.all4tec.matelo.mumgc.capella.importer.ui
Ce plug-in offre la partie interface homme machine. Pour générer un modèle d’usage MaTeLo à partir d’un ensemble de Exchange Scénarios, nous avons ajouté un menu Ma-TeLo dans le gestionnaire de wizard de Capella comme affiché dans la figure4.17.
FIGURE4.17 – Wizard Capella
Lorsque l’utilisateur clique sur ce menu, une fenêtre s’affiche permettant de choisir : — Le modèle Capella à utiliser
— L’architecture du modèle Capella à utiliser — Le nom du projet MaTeLo qui sera créé
Ce fenêtre est présenté dans la figure4.17. Lorsque l’utilisateur clique sur le bouton Fi-nish, notre algorithme commence à s’exécuter.
FIGURE4.18 – Page de Wizard génération d’un modèle d’usage à partir de Capella
A la fin de la génération d’un modèle d’usage, nous aurons un nouveau projet dans MaTeLo contenant le modèle d’usage généré comme présenté dans la figure4.19
Nous avons également fusionné les deux outils MaTeLo et Capella, qui est également basé sur la plateforme Eclipse, dans un seul outil afin de faciliter le travail des ingénieurs souhaitant utiliser notre solution. La figure 4.20montre l’outil qui fusionne MaTeLo et Capella où on peut voir trois zones :