Conception et développement de composants de tests unitaires de Workflow

Transcription

1 Université de Franche-Comté Faculté de Sciences Laboratoire d Informatique de Franche-Comté Rapport du stage effectué du 9 février 2009 au 30 juin 2009 dans la société SKINsoft à Besançon Maître de stage : Nel Taurisson Tuteur universitaire : Fabrice Bouquet Conception et développement de composants de tests unitaires de Workflow Solaine Durpoix

2 2

3 Remerciements Je tiens à remercier M. Geoffroy Rigoulot et Mme Pascale Linderme pour m avoir accueillie au sein de leur entreprise dans le cadre de mon stage, ainsi que M. Nel Taurisson pour m avoir soutenue et guidée pour son bon déroulement. Bien que M. Ciprian Melian ne soit pas présent en permanence dans les locaux de SKINsoft, je tiens tout de même à le remercier pour son accueil. Concernant la rédaction de mon rapport, je suis reconnaissante à Mme Liliane Durpoix, M. Nel Taurisson et M. Fabrice Bouquet pour leur participation. 3

4 Table des matières Remerciements 3 Introduction 7 1 Présentation du stage Présentation de l entreprise SKINSOFT Son organisation Son métier Son logiciel Son partenaire : Nuxeo Contexte du stage Qu est-ce qu un workflow? Pourquoi les workflows? La mission du stage Outils utilisés Méthode de travail : SCRUM Déroulement du stage Familiarisation avec le moteur de workflow jbpm Présentation Les différents éléments d un workflow jboss Présentation des différentes notions d un workflow jbpm à travers la description d un exemple Premier test : test de couverture et de détection de cycle Détection de cycles Test de couverture Modélisation des comportements utilisateurs grâce à des mock users Définition d un Mock Object Gestion des Mock Users Second test : vérification de règles métier

5 2.4.1 Présentation du système de gestion de règles métier : Drools (ou jboss rules) Principe du test Adaptation des tests pour les workflows Nuxeo Spécification des Mock Users pour les workflows Nuxéo Formalisation des règles grâce à un DSL Présentation d un workflow Nuxeo Bilan du stage 31 Conclusion 33 Glossaire 33 Webographie 35 A Test guide 36 B Nuxeo test guide 47 5

6 Table des figures 2.1 Exemple de workflow : relecture d articles Décomposition d un token dans un noeud de type fork Exemple de rapport de couverture Diagramme de classes des utilisateurs virtuels Exemple de règle métier Exemple de workflow Nuxeo : acquisition d oeuvre(s) Premier exemple de règles métier Deuxième exemple de règles métier

7 Introduction Durant ma deuxième année de Master Informatique spécialité Sécurité et Sûreté du Logiciel à l Université de Franche-Comté, je dois réaliser un stage en entreprise. Celui-ci doit se dérouler sur une période de 16 semaines minimum. La société SKINsoft m a accueillie en son sein pour l y effectuer du 9 février au 30 juin. La société SKINsoft est une société de Recherche et Développement en Informatique. Son domaine de recherche est l univers des musées. Son logiciel, SKINmuseum, offre une solution de gestion de collections. Le but de mon stage est de réaliser un composant junit qui permette de tester facilement l application. Deux personnes m encadrent : mon tuteur, M. Fabrice Bouquet, Professeur à la faculté, qui a pour rôle d intervenir ponctuellement comme, par exemple, pour effectuer la visite de stage ou encore me conseiller dans l élaboration de mon rapport mon maître de stage, M. Nel Taurisson, l ingénieur Recherche et Développement de SKINsoft, qui me délivre mes objectifs et suit la progression de mon travail. Après une brève présentation de SKINsoft, je vais vous présenter le contexte de mon stage, puis son déroulement. Enfin, je vous exposerai le bilan de mon stage. 7

8 Chapitre 1 Présentation du stage Ce premier chapitre va me permettre d une part de vous présenter l entreprise dans laquelle j ai effectué mon stage et d autre part, le contexte de mon stage. 1.1 Présentation de l entreprise SKINSOFT SKINsoft est une société de Recherche et Développement en Informatique, créée le 1 er avril Son organisation Son effectif actuel est de trois personnes : - gestion d entreprise, stratégie marketing et développement commercial : Geoffroy RIGOULOT - management : Ciprian MELIAN - ingénierie R&D : Nel TAURISSON Geoffroy Rigoulot et Ciprian Melian sont les co-gérants de SKINsoft. Geoffroy RIGOULOT dirige depuis 1986 en co-gérance avec Pascale Linderme sa propre entreprise, L AGENCE PRIVEE LRG associés, de conseil marketing et communication, en France et à l international. De plus, il est le gérant d une société de conception, fabrication et distribution de meubles contemporains pour l univers des musées : Plan Libre. Ciprian MELIAN dirige également depuis 2002 sa propre entreprise, Melian Multimedia, de services internet et multimédia. 8

9 1.1.2 Son métier Le domaine de recherche de SKINsoft est l univers des musées. Sa vocation est de développer un ensemble d innovations technologiques, et de nouer des partenariats avec les acteurs de ce marché pour leur permettre de disposer d une offre performante, à la pointe de la technologie. La première phase de recherche et développement de SKINsoft a abouti à la stabilisation début janvier de l application SKINmuseum Son logiciel SKINmuseum offre une solution de gestion des collections de musées riche, flexible et adaptable aux spécificités métier. Il s agit d une solution client / serveur (client accessible depuis n importe quel navigateur web, serveur multi-plateforme) qui ouvre la porte à une gestion collaborative des collections. Les bases de cet outil sont entièrement libres puisqu elles reposent sur les technologies JAVA/JEE et JBoss. L application fonctionne à l Hôtel Dieu des Hospices de Beaune, et est en phase d installation au Musée d Art et d Histoire de la ville d Auxerre. De plus, SKINsoft a décroché mi-mai le contrat d équipement du Centre National du Costume de Scène de Moulins Son partenaire : Nuxeo Alors que le logiciel n était pas encore créé, mais seulement pensé, une analyse fut faite sur le choix des technologies à utiliser. Une des premières spécifications techniques définies fut la nécessité que le logiciel soit full web. Dès lors, soit SKINsoft choisissait de développer le logiciel à partir d un framework léger type Php, soit l entreprise basait son logiciel sur une plateforme de gestion de contenu (ECM) déjà existante. L idée d utiliser php a vite été écartée car pour créer un noyau adaptable, il est nécessaire d avoir une vraie architecture composants que n offre pas les Frameworks Php existants. De plus, son mode d exécution (envoi de requêtes et de réponses) ne permet pas de développer des applications de la complexité de celles visées. Une recherche fut donc faite pour trouver un système de gestion documen- 9

10 taire : Nuxeo EP et Alfresco sortirent du lot. Après une analyse poussée de ces deux systèmes, Nuxeo EP, produit de l entreprise Nuxeo, fut retenu. Cette ECM permet de gérer des documents dans des processus métiers. Par exemple, les oeuvres d un musée (documents) doivent être correctement gérées lors d un prêt (processus métier) à un autre musée. Nuxeo est un éditeur de logiciels d applications Open Source dans le domaine de la gestion de contenu d entreprise et de la GED, basées sur les technologies Java EE 5. La société a été fondée en 2000 par Stéfane Fermigier. Outre le fait que leur produit soit actuellement la base de SKINmuseum, la société NUXEO ( CA de 3 millions d euros en 2008 ) est entrée au capital de SKINsoft en février Depuis, les deux sociétés mènent conjointement des actions de Recherche et Développement. 1.2 Contexte du stage Les processus métiers du logiciel SKINmuseum sont implémentés par des workflows. Dans un premier temps, je vais vous présenter le concept des workflows, puis leur rôle dans l application. Ces deux premières parties m amèneront ensuite à la description de la mission de mon stage. Le rôle de mon stage étant présenté, je vous décrirai la partie technologique du contexte de mon stage. Enfin, je conclurai en vous présentant la méthode de travail que nous avons choisi d utiliser avec mon responsable, pour mener à bien mon stage Qu est-ce qu un workflow? On appelle «workflow» (que l on traduit littéralement par «flux de travail») la modélisation et la gestion informatique de l ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d un processus métier. Le terme de «workflow» pourrait donc être traduit en français par «gestion électronique des processus métier». SKINmuseum étant destiné à des musées, les workflows qui y sont implémentés permettent de gérer des processus métiers de la muséologie tels que l acquisition d une oeuvre, ou son récolement. Les workflows sont implémentés dans Nuxeo avec la librairie jbpm éditée 10

11 par jboss. Comme il l a été dit précédemment (cf ), Nuxeo EP permet de gérer des documents dans des processus métier. Ainsi, Nuxeo a spécialisé la gestion des workflows faite par jboss pour y intégrer la gestion des documents dans les processus métier. Nous pouvons donc dire que même si la base d implémentation des workflows est celle de jbpm, Nuxeo a créé un nouveau type de workflow, que nous appelerons par la suite, les workflows Nuxeo Pourquoi les workflows? Dans la plupart des entreprises de développement de logiciels, les contrats sont définis par deux entités : - MOA : Maitrise d ouvrage, entité présente chez le client - MOE : Maitrise d oeuvre, entité présente dans l entreprise de développement La MOA n est pas souvent le vrai client du logiciel c est-à-dire le futur utilisateur, mais une sorte d intermédiaire. En effet, la MOA a pour rôle de définir, à partir des souhaits du client, les spécifications fonctionnelles du logiciel. Ensuite, elle transmet ces spécifications à la MOE, qui va se charger de les transformer en spécifications techniques et de les implémenter. Dans le monde du musée, nous pouvons identifier le client par le conservateur, et la MOA comme étant le service informatique ou un consultant du musée. Dans notre cas, la MOE correspond à SKINsoft. Une des difficultés de ce système est d arriver à définir des spécifications fonctionnelles qui soient claires pour toutes les entités. SKINsoft a donc décidé d utiliser des modèles graphiques pour formaliser les spécifications. Les spécifications fonctionnelles se décomposent chez SKINsoft en deux parties : schémas des données et des rôles processus métiers Dans un premier temps, l entreprise définissait avec ses clients les différents schémas de données (structure des différents types d oeuvres du musée, différentes permissions d accès...) à l aide d UML. Les processus métiers étaient quant à eux définis textuellement, puis définis graphiquement sans le client grâce à des workflows. La plateforme Nuxeo EP contient seulement deux workflows. Ainsi, bien que toute la gestion de documents dans les workflows soit mise au point, les workflows restent très anecdotiques dans la plateforme. Cependant, SKINsoft a fait le choix de fonder toute l implémentation de ses processus métier sur 11

12 cette technologie. L objectif premier de SKINsoft est donc de définir ces processus graphiquement, avec le client. De plus, l entreprise souhaiterait ajouter une spécification de règles métiers à la spécification fonctionnelle. Les règles métier (ou business rules ) sont des déclarations de haut niveau structurées, qui permettent de contraindre, contrôler et influencer un aspect du métier. A chaque processus métier peuvent être associées plusieurs règles métier. Leur but est de séparer la logique métier de la logique système ou applicatif dans une application. Ainsi la logique métier pourra évoluer et être maintenue séparément du code de l application La mission du stage Dans le logiciel SKINmuseum, l utilisation des workflows n est pas visible. En effet, c est l interface graphique qui permet de les exécuter. Ainsi, nous pourrions dire que tester les workflows revient à tester l interface graphique. Cependant, d une part, cela n est pas une bonne méthode de test et d autre part, les workflows sont souvent développés avant l interface graphique et doivent donc être testés afin de détecter des erreurs le plus rapidement possible. Néanmoins, la réalisation de tests unitaires pour les processus métiers et leur mise à jour est une tâche fastidieuse. La majorité du code de ces tests n a pour fonction que de faire tourner le workflow et doit être révisé lors de chaque modification. Le but de ce stage est donc d étudier et de réaliser des tests unitaires à partir de la représentation graphique des processus. La majeur partie du code sera un composant junit réutilisable pour tous les workflows, permettant ainsi de limiter la phase de rédaction des tests. Comme il l a été dit dans la section précédente (cf ), un ensemble de règles métier est défini avec le client. Ces règles doivent être absolument respectées, d une part pour assurer au client que le logiciel développé correspond bien à ses attentes et d autre part, pour vérifier tout au long du développement que l on ne s éloigne pas des objectifs définis. Ainsi, une des missions de mon stage est d une part, de trouver un formalisme de représentation des règles métiers et d autre part, d intégrer au composant junit, un test permettant de vérifier qu un workflow respecte bien un certain nombre de règles métier. Il s agit donc d utiliser les techniques de tests unitaire pour réaliser des tests fonctionnels. Cette première partie du stage va donc consister à réaliser un composant 12

13 junit pour les workflows de jboss. La seconde partie sera de spécialiser ce composant pour l adapter aux tests de workflows Nuxeo Outils utilisés Lors de mon arrivée chez SKINsoft, je me suis adaptée à son environnement de travail et notamment aux outils que M. TAURISSON utilisait. Système d exploitation : Linux L ordinateur à ma disposition lors de mon stage était installé avec le système d exploitation Ubuntu, construit autour du noyau Linux. Une des principales raisons qui justifie ce choix est le fait que la technologie java est plus rapide sous Linux que sous Windows. Ensuite, SKINsoft n utilise pas de logiciels non compatibles avec Linux. Environnement de développement logiciel : Eclipse Eclipse IDE est un environnement de développement intégré libre, extensible, universel et polyvalent, permettant potentiellement de créer des projets de développement mettant en oeuvre n importe quel langage de programmation. Dans notre cas, le langage de programmation utilisé est Java. Cet environnement permet à SKINsoft de créer et de gérer l ensemble de ses projets Java à travers l utilisation de nombreux plugins tels que : Subversive : permet de gérer un SVN (Subversion) TeXlipse : permet de créer et de visualiser des documents LaTeX (utilisé pour la rédaction de ce rapport) JBoss Graphical Process Designer : éditeur graphique de workflow (processus métier) Drools : permet de gérer des règles métier plugin pour utiliser Ant, logiciel d automatisation de production de projet Logiciel d automatisation de production de projet : Maven Apache Maven est un outil logiciel libre pour la gestion et l automatisation de production des projets logiciels Java en général. Il est géré par l organisation Apache Software Foundation. Précédemment Maven était une branche de l organisation Jakarta Project. 13

14 Le but de cet outil est comparable à celui du système Make sous Unix : produire un logiciel à partir de ses sources, en optimisant les tâches réalisées à cette fin et en garantissant le bon ordre de fabrication. Il ajoute à ces fonctionalités une gestion puissante des dépendances entre projets. Ant est utilisé pour piloter maven en automatisant des tâches comme le build ou le déploiement vers différents environnements (test, production...) Méthode de travail : SCRUM Scrum est une méthode agile pour la gestion de projets. Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s articule en effet autour d une équipe soudée, qui cherche à atteindre un but, comme c est le cas en rugby pour avancer avec le ballon pendant une mêlée. Le principe de base de Scrum est de focaliser l équipe de façon itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une à quatre semaines, appelées Sprints. Chaque Sprint possède un but à atteindre, défini par le Directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce sprint. Un sprint aboutit toujours à la livraison d un produit partiel fonctionnel. Pendant ce temps, le Scrum- Master a la charge de réduire au maximum les perturbations extérieures et de résoudre les problèmes non techniques de l équipe. Un principe fort en Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel, et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en cours de réalisation pendant un sprint. Dans le cadre de mon stage, le Directeur de produit est Geoffroy RI- GOULOT et le ScrumMaster, Nel TAURISSON. La durée d un sprint est de 1 semaine (5 jours travaillés). Pour appliquer cette méthode jusqu au bout, nous avons choisi un nom pour le projet : JbpmUnit, combinaison de Jbpm et de JUnit. Vous ayant présenté le contexte de mon stage, ja vais désormais vous présenter son déroulement de manière chronologique. 14

15 Chapitre 2 Déroulement du stage La première partie de ce rapport m a permis de vous présenter le lieu de mon stage et la seconde, son contexte. Ce troisième chapitre, quant à lui, va me permettre de vous exposer le contenu du stage, c est-à-dire les différentes tâches que j ai effectuées chez SKINsoft au cours des quatre mois de mon stage. 2.1 Familiarisation avec le moteur de workflow jbpm Lors de mon arrivée chez SKINsoft, il me fallut découvrir les différentes technologies sur lesquelles j allais travailler. La principale et également celle que je ne connaissais pas fut celle des workflows de jboss. Je vais donc vous les présenter dans cette partie, puis je vous décrirai l exemple de workflow qui m a permis de me familiariser avec la technologie jbpm Présentation JBPM est un logiciel libre développé par JBoss, écrit en java. C est un moteur de workflows, dans lequel chaque workflow (processus métier) est décrit dans un fichier XML : définition du processus. Ce fichier décrit également les classes java utilisées pour le traitement des données (API JBPM). Un workflow étant plus explicite graphiquement, il est bien évidemment possible de le créer graphiquement. L éditeur graphique que j ai utilisé est le plugin Eclipse JBoss Graphical Process Designer. Il permet de passer d une vue graphique du processus sous forme de graphe orienté à une vue sous format XML. La synchronisation des deux vues est gérée, ainsi il est possible de modifier le fichier XML et d en voir la résultante sous format 15

16 graphique Les différents éléments d un workflow jboss Démarrer un workflow signifie créer et exécuter une instance du processus. Et tout comme il est possible de créer plusieurs instances d une même classe Java, plusieurs instances du même processus peuvent être exécutées en même temps. Au démarrage d un workflow, un jeton est créé. Ce jeton suit le chemin d exécution du processus et peut se décomposer en jeton fils. Cependant, les jetons ne se déplacent pas en même temps ; nous restons dans du parcours séquentiel. Il est possible de stocker des variables dans le contexte de l exécution, ainsi que sur un jeton. Ces variables permettent de manipuler les objets métiers liés au processus. Au niveau structurel, un processus est composé de noeuds et de transitions sur lesquels des actions (code Java ou script) peuvent être exécutées. Pour une meilleure compréhension des sections du rapport qui vont suivre, je vais vous présenter ces différentes notions à travers un exemple. La description de l exemple qui va suivre va vous permettre de mieux cerner la fonction de chaque élément précédemment présenté Présentation des différentes notions d un workflow jbpm à travers la description d un exemple L exemple qui me permit de me familiariser avec l implémentation des workflows est l exemple de workflow de la relecture d articles. Ce processus métier se décompose en plusieurs étapes. Un utilisateur soumet un article pour qu il soit relu et ensuite, choisit un ensemble de relecteurs. Chacun des relecteurs a pour rôle d attribuer une note à l article. Une fois que l article a été noté par tous les relecteurs, sa moyenne est calculée. Il est possible de soumettre plusieurs articles. Lorsqu il n y a plus d articles à soumettre, une sélection est faite de telle sorte que seuls les articles qui ont une moyenne supérieure à 10 sont sélectionnés. Cet exemple va me permettre de vous présenter les différentes notions des workflows jbpm. Je vais vous présenter le workflow à travers la description de son exécution (cf. figure 2.1). 16

17 Fig. 2.1 Exemple de workflow : relecture d articles. Le processus démarre par le noeud start de type start-state. Un graphe doit posséder exactement un noeud de ce type pour permettre au processus de démarrer. Comme il l a été dit précédemment, le token / est créé au démarrage du processus et parcourt l ensemble des noeuds et des transitions du graphe. Le premier élément qu il parcourt, après le noeud start, est la transition starttosubmission. Une transition est un arc orienté qui permet de faire passer un jeton d un noeud à un autre. Autre que le noeud de type start-task, notre exemple de graphe est constitué de quatre autres types de noeuds : task-node : ce type de noeuds représente une ou plusieurs tâches qui doivent être exécutées par un utilisateur. Par exemple, le noeud submission représente la soumission d un article par un utilisateur. Tant que cet utilisateur n aura pas valider la soumission, l exécution du processus sera en attente sur ce noeud. Ces tâches représentent le plus souvent des actions effectuées sur une 17

18 Fig. 2.2 Décomposition d un token dans un noeud de type fork. interface graphique reliée au workflow. Lors de l implémentation de ce workflow, n ayant pas mis au point d interface graphique, j ai créé une fonction pour chaque tâche de chaque task-node dans la classe de test. Cette méthode de test est très statique mais était suffisante dans un premier temps. join : lorsqu un jeton arrive sur ce noeud, il y est bloqué tant que tous les jetons qui ont le même parent que lui ne sont pas arrivés. Une fois qu ils sont tous arrivés, le noeud termine l exécution de chaque jeton fils et c est le parent qui continue l exécution. Ce noeud permet ainsi de rassembler un ensemble de chemins d exécution. end-state : c est le dernier noeud d un graphe : dans cet exemple, c est le noeud end. Il peut y en avoir plusieurs dans un même graphe, mais dès que l on arrive sur l un de ces noeuds, l exécution s arrête. node : ce type de noeud est utile lorsque l on veut exécuter du code Java. Le noeud final list of articles est un noeud de ce type dont l action permet de ne sélectionner que les articles qui ont une moyenne supérieure à 10. Un autre type de noeud existe mais n est pas utilisé dans cet exemple : Fork. Contrairement à un noeud de type Join, ce type de noeud permet de découper un chemin d exécution. Un token fils, de celui entré dans le fork, est créé pour chaque transition qui quitte le noeud (cf figure 2.2 : le token / se décompose en trois sous-token t1, t2 et t3 qui deviennent ses fils). Pour implémenter la logique métier du processus, comme par exemple calculer la moyenne d un article, des actions sont implémentées. Les actions Une action est un bout de code Java qui est exécuté lors de l exécution du processus. Les actions permettent d ajouter des détails techniques en dehors de la 18

19 représentation graphique : le code Java peut être associé au graphe sans changer la structure du graphe. Les actions sont généralement placées sur des événements : - événement sur un noeud (tous types) : node-enter (entrée sur le noeud), node-leave (sortie du noeud) - événement sur une transition : transition - événement sur un noeud de type task-node : task-start (démarrage d une tâche), task-create (création d une tâche), task-assign (assignation d une tâche à un utilisateur) et task-end (fin d une tâche). Un événement de ce type sera déclenché pour chaque tâche du noeud. - événement sur le processus : process-start (démarrage du processus) et process-end (fin du processus) Cependant, il est également possible de les placer directement sur un noeud comme cela est fait pour le noeud final list of articles : les actions sont exécutées lorsqu un token arrive sur le noeud. Cet exemple nous montre que nous ne sommes pas limités à l utilisation des seuls noeuds jbpm. En effet, pour créer les noeuds fork :each reviewer et join :each article, j ai repris les fonctionalités du fork et du join et j y ai ajouté ce dont on avait besoin et qui n était pas géré par le fork et le join de jbpm. Ayant cerné la plupart des notions des workflows jbpm, j ai pu débuter la principale mission de mon stage, c est-à-dire tester ces workflows. 2.2 Premier test : test de couverture et de détection de cycle. Ce premier test se décompose en deux parties : le test de détection de boucles et le test de couverture Détection de cycles La première partie du test consiste à détecter s il y a des boucles dans un workflow. Pour ce faire, une action est ajoutée automatiquement sur chaque transition (événement transition) et sur chaque noeud du workflow (événement nodeenter), avant le démarrage de l exécution du processus. L action ajoutée a pour but d augmenter le compteur du noeud ou de la transition où est placée 19

20 l action. Ainsi, dès qu un token passe une transition (ou entre dans un noeud), l action se déclenche et le compteur de la transition (ou du noeud) augmente. Ayant un moyen de connaître le nombre de passages dans une transition ou dans un noeud, il reste à définir à partir de combien de passages il faut considérer qu une boucle doit être détectée. Ce choix est laissé au testeur. Au déclenchement de l action, si le compteur maximum est atteint pour une transition ou un noeud, le test échoue en précisant l endroit ( noeud ou transition ) où se situe la boucle. De plus, il est possible de configurer ce test pour qu il attribue un compteur à chaque token qui passe sur chaque noeud et chaque transition. Par exemple, si deux tokens passent sur un noeud, alors ce noeud possèdera deux compteurs : un pour chaque token. Cela permet donc d affiner le test de bouclage Test de couverture A la fin du test de bouclage est affiché un rapport de couverture des noeuds et des transitions du graphe. Cela consiste simplement à récupérer les compteurs de l ensemble des noeuds et des transitions et à les afficher (cf. figure 2.3). Le test de couverture permet de détecter si un noeud ou une transition n est jamais visité(e). Si au moins un noeud ou une transition n est pas visité(e), le test devient KO (cf. figure 2.3). Ce test n est pas réellement un test puisque si un noeud n est pas visité, le test junit n échoue pas ; c est la raison pour laquelle il se trouve à la fin du test de détection de boucles et n est pas un test indépendant. 2.3 Modélisation des comportements utilisateurs grâce à des mock users Comme il l a été précisé dans la partie 2.1.3, pour faire tourner l exemple de workflow qui m a permis de me familiariser avec jbpm, j ai dû créer des méthodes pour chaque tâche de chaque noeud de type task-node. Cette technique est très statique et ne donne pas la possibilité au testeur d attribuer des actions différentes pour une même tâche et de tester le workflow avec plusieurs utilisateurs. L idée fut alors de trouver un formalisme de description et d implémentation de comportements utilisateurs. 20

21 Fig. 2.3 Exemple de rapport de couverture Définition d un Mock Object En programmation orientée objet, les mock objects sont des objets virtuels qui imitent le comportement de vrais objets. Ils sont généralement créés pour tester le comportement d autres objets. Dans notre cas, le testeur crée des utilisateurs virtuels pour tester la structure et le fonctionnement du workflow Gestion des Mock Users A partir du moment où un workflow contient au moins un noeud de type task-node, il est nécessaire de créer des utilisateurs virtuels pour le tester. Il existe deux types d utilisateurs virtuels (cf. figure 2.4). 21

22 Le premier type est DefaultMockUser : ce type de Mock User correspond, comme son nom l indique, à un Mock User par défaut. Il se contente de terminer la tâche. Donc ce type de Mock user convient pour des tâches qui n ont pas d influence sur le reste de l exécution du workflow, comme par exemple, une tâche où l utilisateur aurait juste un formulaire à remplir et que ce formulaire ne serait jamais consulté par la suite. Le deuxième type de Mock User est à l inverse du premier totalement configurable : AbstractMethodBasedMockUser. En effet, cette classe Java est abstraite et demande à être implémentée par une ou plusieurs classes filles. Implémenter les classes filles signifie y créer des méthodes pour les tâches. Nous restons ainsi dans le principe de départ qui consistait à créer une méthode pour chaque tâche du workflow. La grande différence est qu il est désormais possible d en créer plusieurs pour une même tâche et dans des Mock Users différents. Ainsi, deux classes filles peuvent contenir des méthodes pour la même tâche. Fig. 2.4 Diagramme de classes des utilisateurs virtuels. Le testeur peut créer autant d utilisateurs virtuels qu il le souhaite de chacun des deux types. Choix d un utilisateur virtuel Par défaut, lorsqu un jeton arrive sur un noeud de type task-node, un utilisateur virtuel est choisi presque au hasard parmi ceux créés par le testeur. En effet, si l utilisateur choisi est de type AbstractMethodBasedMockUser, une vérification est faite pour savoir s il possède ou non une méthode compatible pour la tâche. Si ce n est pas le cas, un autre utilisateur est choisi. En revanche, si l utilisateur est du premier type, rien ne peut empêcher ce 22

23 choix. Cependant, comme il l a été dit précédemment, les utilisateurs de type DefaultMockUser doivent être utilisés seulement pour des tâches dont l action n a pas d incidence sur le reste du workflow. Dans le cas contraire, cela peut poser problème pour le reste de l exécution du workflow. Pour pallier ce problème et pour laisser la possibilité au testeur de créer en même temps des utilisateurs des deux types, deux listes ont été attachées à chacun des deux types. Ces listes sont destinées à contenir des noms de tâches et ont été créées sur le principe de liste noire (LN) et de liste blanche (LB) : si une tâche se trouve dans LB et pas dans LN, alors elle est acceptée si une tâche se trouve dans LB et dans LN, elle est refusée si LB est vide, toutes les tâches ne se trouvant pas dans LN sont acceptées si LB n est pas vide et qu une tâche ne se trouve dans aucune des deux listes, alors elle est refusée. Le testeur peut ainsi remplir les listes de chacun de ses utilisateurs virtuels comme il le souhaite. Par exemple, si une tâche du workflow ne doit absolument pas être effectuée par un utilisateur de type DefaultMockUser, il doit ajouter le nom de cette tâche dans la liste des tâches non acceptées (boite noire) de chacun des utilisateurs qui sont de ce type. Choix d une méthode Le nom des méthodes implémentées dans un Mock User doit suivre une syntaxe très particulière : task{nomtâche}{nomméthode}. C est cette syntaxe qui va permettre la sélection d une méthode pour une tâche. Cette sélection est aléatoire. Une autre configuration est possible : elle concerne le choix des utilisateurs virtuels et celui des méthodes. Ces choix peuvent être avec ou sans remise, c est-à-dire que si un utilisateur a été choisi, il ne sera plus choisi tant qu il y aura encore d autres utilisateurs compatibles avec la tâche et qui n ont jamais été sélectionnés. Il en est de même pour le choix des méthodes. L intérêt de cette configuration est de tester au maximum le workflow. 2.4 Second test : vérification de règles métier Le premier test qui a été implémenté permet de tester la structure d un workflow. Le second a, quant à lui, pour but de le tester fonctionnellement en vérifiant qu il respecte bien un certain nombre de règles qui doivent être 23

24 définies avec le client Présentation du système de gestion de règles métier : Drools (ou jboss rules) Drools (ou JBoss Rules) est un système de gestion de règles métier (ou SGRM) utilisant un moteur d inférence à chaînage avant. C est un logiciel libre distribué selon les termes de la licence Apache. Un moteur d inférence permet aux systèmes experts de conduire des raisonnements logiques et de dériver des conclusions à partir d une base de faits et d une base de connaissances. La base de faits est, dans notre cas, la logique métier implémentée dans le workflow et la base de connaissances correspond aux règles métier. Travaillant sur des workflows jbpm, il fut assez logique de choisir le SGRM du même serveur d applications. De plus, ce SGRM est écrit en Java. Les règles métier implémentées dans Drools se décomposent en deux parties distinctes : when : partie d une règle où sont définies les différentes conditions qui doivent être vérifiées. La syntaxe des conditions est particulière dans le sens où c est le constructeur d un objet qui est utilisé pour définir la condition. Les règles permettent ainsi de tester les attributs d objets Java. then : partie d une règle qui n est exécutée que lorsque les conditions définies dans le then sont respectées. Le code écrit dans cette partie est du code Java. La figure 2.5 montre un exemple de règle métier qui teste un objet de la classe Message. L attribut status est testé et l attribut message est récupéré (usage de : ) et mis dans une variable message. Cette variable est ensuite affichée si la condition n est pas respectée. Fig. 2.5 Exemple de règle métier. 24

25 Plus simplement, cette règle permet d afficher la proriété message d un objet de type message lorsque sa propriété status a pour valeur Message.GOODBYE. Pour pouvoir définir des conditions sur des objets Java, ceux-ci doivent au préalable être insérés dans le moteur avant son lancement Principe du test Vérifier qu un workflow respecte des règles métier revient à vérifier que la logique métier du processus est correct. Ainsi, les règles métier travaillent sur les objets métier liés au processus et donc sur les variables du contexte du workflow (cf. section 2.1.2). Etant donné que le contexte du processus change après chaque déplacement d un jeton ou chaque exécution d une action, il n est pas suffisant de ne vérifier qu une seule fois le respect des règles, comme par exemple à la fin de l exécution du processus. Ainsi, avant le démarrage du workflow, la définition du processus est automatiquement modifiée de telle façon qu une action est ajoutée sur tous les événements existants pour chaque élément du workflow. Sur certains événements, l action est ajoutée avant toutes les autres actions de l événement et sur d autres, elle l est après. Cela permet de vérifier le respect des règles avant ET après l exécution d une ou plusieurs actions. événements sur lesquels l action est ajoutée avant toutes les autres : node-enter, task-create, task-start, task-assign événements sur lesquels l action est ajoutée après toutes les autres : node-leave, transition, task-end L action qui est ajoutée a pour but de lancer le moteur d inférence du SGRM sur le fichier de règles. Avant d effectuer ce lancement, les variables du contexte sont insérées dans la session du moteur de règles. Ces variables représentent ainsi la base de faits que le moteur va comparer à la base de connaissances que représentent les règles métier. Lorsqu une règle n est pas respectée, le code Java du when est exécuté. La personne qui effectue ce test est également celle qui écrit le fichier de règles. Ainsi, elle a le choix entre faire échouer le test junit ou simplement afficher un message signalant le non-respect de la règle. A ce stade du rapport, la première partie de mon stage est terminée puisque la première version du composant junit est en état de marche. Ce composant se nomme JbpmUnit. J ai réalisé une documentation, pour l utilisation du composant junit, qui se trouve en annexe A. 25

26 La deuxième partie du stage consiste à spécialiser ce composant pour qu il permettre de tester des workflows Nuxeo. Cette spécialisation résulte donc en un nouveau composant intitulé JbpmUnitNuxeo. Sa documentation se trouve en annexe B. Dans la section suivante, je vais vous présenter la spécialisation de JbpmUnit. 2.5 Adaptation des tests pour les workflows Nuxeo La principale différence entre les workflows basiques de jbpm et ceux de Nuxeo est la gestion de documents. En effet, Nuxeo a intégré à sa plateforme une sur-couche à l implémentation des workflows jbpm. Cette sur-couche permet à tout utilisateur de leur plateforme de créer des workflows consacrés à la gestion de documents, comme c est le cas pour SKINsoft. Mon responsable et moi avons choisi de dissocier le test de workflows jbpm de celui de workflows Nuxeo. Un nouveau composant de test fut alors créé : JbpmUnitNuxeo. Cependant, bien que les deux tests soient dissociés, les composants ne le sont pas complètement puisque JbpmUnitNuxeo spécialise JbpmUnit Spécification des Mock Users pour les workflows Nuxéo Dans un workflow, une tâche doit généralement être assignée à un ou plusieurs acteurs. Une convention pour l assignation des tâches a été mise en place dans la plateforme Nuxeo ; une tâche peut être assignée de trois manières différentes : assignation à un utilisateur U : user :U assignation à un groupe d utilisateurs G : group :G assignation à une permission P : permission :P Les Mock Users ont donc été spécifiés pour y intégrer cette convention. Le testeur, après avoir créé un mock user, doit lui attribuer un utilisateur Nuxeo de type NuxeoPrincipal. Il est possible d ajouter cet utilisateur à un groupe et de lui attribuer différentes permissions sur des documents. Cette spécification est présente uniquement dans le composant JbpmUnit- Nuxeo. Lors de la sélection d un mock user, un test permet de savoir si l utilisateur 26

27 virtuel choisi peut ou non exécuter la tâche. Ce test consiste tout d abord à récupérer l ensemble des éléments associés à l utilisateur Nuxeo du mock user sélectionné, et ceci en suivant la convention Nuxeo : le nom de l utilisateur Nuxeo est récupéré et préfixé par user : chacun des groupes dont fait partie l utilisateur Nuxeo est précédé par group : chacune des permissions attribuées à l utilisateur Nuxeo est précédée par permission : Ensuite, le test consiste à vérifier parmi l ensemble récupéré, si au moins un des acteurs de la tâche s y trouve. Si c est le cas, ce test est validé et un second test est alors exécuté : vérifier s il existe une méthode pour la tâche (cf. section ) Formalisation des règles grâce à un DSL Comme il l a été présenté dans la section 1.2.2, un des souhaits de SKINsoft était de pouvoir définir les règles métier avec le client, avant l élaboration du workflow. Pour rendre cette tâche plus simple, un langage dédié (DSL) fut mis au point. Dans notre cas, un DSL consiste, à partir d un ensemble de règles de réécriture proche du langage naturel, à générer du langage Drools. Voici un exemple simple de règles de réécriture du DSL : logobject object = System.out.println(object) ; Avec cette règle, le logobject sera réécrit textuellement par un System.out.println. Fonctionnellement, elle permet d afficher un objet Java Présentation d un workflow Nuxeo L exemple de workflow que je vais vous présenter correspond à l acquisition d une ou plusieurs oeuvre(s) dans un musée (cf. figure 2.6). Ce workflow est un workflow de gestion documentaire : il permet de gérer des oeuvres qui sont des documents, au sein d une acquisition qui elle-même est un document. De façon générale, les workflows Nuxeo sont liés à la gestion documentaire et permettent de : - créer un ou des documents - lier des documents par des relations - contrôler les propriétés des documents 27

28 Fig. 2.6 Exemple de workflow Nuxeo : acquisition d oeuvre(s). - modifier le cycle de vie des documents Dans notre exemple, au commencement du workflow, le document acquisition est dans le cycle de vie project et à la fin, il sera dans celui validé. Gestion des permissions Ce workflow comprend trois noeuds de type task-node qui se composent chacun d une seule tâche. Tous les utilisateurs ne peuvent pas réaliser une acquisition : la tâche de modification de l acquisition est une tâche que le musée peut choisir de déléguer. en revanche, la validation de l acquisition et l explication du refus de la validation sont des tâches qui doivent être réalisée par un responsable du musée, en général, le conservateur. Ce workflow se compose donc de deux permissions différentes : inventorier(employé du musée ou personne extérieur) et inventorymanager(responsable du musée), auxquelles sont assignées les tâches. Pour tester ce workflow, deux utilisateurs virtuels furent donc créés, chacun possédant une des deux permissions précédentes. 28

29 Mise en place de règles métier Un certain nombre de règles métier ont été implémentées afin de tester fonctionnellement le workflow. Au départ, le DSL mis en place ne comprenait que les règles de base. Il fut ensuite enrichi, au fur et à mesure des besoins lors de l écriture des règles métier. Deux règles métier ont été mises en place pour tester le cycle de vie des documents. La première règle est placée sur l événement node-enter du noeud modifier l acquisition. Elle récupère le document de l acquisition qui a été créé lors du démarrage du workflow, puis teste son cycle de vie (cf. 2.7). Fig. 2.7 Premier exemple de règles métier. La seconde règle est placée sur l événement node-enter du noeud acquisition validée. Tout comme la première, elle récupère le document de l acquisition. Le test du cycle de vie se trouve dans la partie when ; ainsi si le document n est pas dans le cycle de vie inventoried, la règle ne se déclenchera pas. Ensuite, dans la partie then se trouve le test du cycle de vie des documents correspondant à toutes les oeuvres qui doivent être acquises. Pour ce faire, deux règles ont été mises en place dans le DSL qui permettent de récupérer des documents à travers l exécution d une requête NXQL (langage de requêtes de Nuxeo). La première permet d ajouter, à la requête, des paramètres qui seront insérés dans la requête à la place des points d interrogation (cf. figure 2.8). Il n est pas obligatoire d écrire les règles entièrement avec le DSL. En effet, il est possible d y intégrer du code Java, qui doit cependant être précédé de > pour être reconnu comme du non DSL. 29

30 Fig. 2.8 Deuxième exemple de règles métier. 30

31 Chapitre 3 Bilan du stage Contrairement à mon stage de Licence 3, à mon arrivée chez skinsoft, tout était défini et je savais exactement ce que j allais faire pendant plusieurs semaines. En effet, mon stage était découpé en itérations. La première itération a consisté à me familiariser avec les différents outils qu utilise SKINsoft. Cette tâche fut aux premiers abords difficile car je ne connaissais ni les workflows jbpm, ni l outil Maven. Cependant, avec l aide de mon responsable, elle se révéla moins compliquée qu elle n en avait l air. Ensuite, une fois les notions appropriées, la continuité du stage se déroula normalement et même plutôt rapidement. En effet, j ai eu terminé l implémentation des composants junit au bout de trois mois. Ce ne fut en aucun cas une mauvaise chose puisque j ai pu découvrir une partie de l application SKINmuseum. En effet, jusqu alors, je n avais pas du tout travailler dessus. Le travail qui me fut confié était de créer des workflows pour l application et ensuite d utiliser le composant junit que j ai réalisé pour les tester. J en retire une certaine fierté puisqu il fonctionne en grandeur nature. Ainsi, mon travail a porté ses fruits. Un autre avantage de cette avance fut le fait que j ai pu commencer tôt la rédaction du rapport et ainsi ne pas être bousculée pour la terminer. Etant donné que mi-juin la date d installation de SKINmuseum au Musée d Art et d Histoire d Auxerre approchait, j ai également pu prendre part à la phase de récupération des données qui est la dernière étape avant l installation du produit. Je ne retire de ce stage que des points positifs. J ai appécié le côté familial chez SKINsoft et également la diversité d activités qui s opèrent dans les locaux puisque c est le lieu de travail de trois sociétés aux activités différentes : SKINsoft, L Agence Privée et Plan Libre. 31

32 Du point de vue du travail, c est également le cas, je ne trouve pas de point négatif étant donné que j ai réalisé des choses intéressantes, rentrant dans le cadre de ma formation mais ayant également une part d inconnu. J ai ainsi eu l occasion d apprendre un certain nombre de choses. 32

33 Conclusion Actuellement, on peut dire que tous les objectifs de mon stage ont été atteints puisque le composant junit que j ai réalisé fonctionne et que j ai moi-même pu tester son fonctionnement sur l application SKINmuseum. Mon stage chez SKINsoft fut agréable de part l ambiance qui règne dans les locaux. De plus, il fut très instructif et très enrichissant pour moi, mais également pour l entreprise à qui j ai pu apporter mes compétences en test. Mon responsable a d une part apprécié mon travail et ma rapidité d adaptation. Après une discussion entre Nel Taurisson, Ciprian Melian et Geoffroy Rigoulot, la décision fut donc prise de m embaucher pour continuer cette collaboration. Mon stage s étant très bien déroulé, j ai accepté cette offre d embauche qui va me permettre d entrer dans la vie active après une formation de cinq années après le baccalauréat. Je remercie donc Geoffroy Rigoulot et Ciprian Melian pour cette confiance qu ils m accordent. 33

34 Glossaire full web Outil qui permet de se connecter à son système d information à partir de n importe quel terminal relié à internet. 6 DSL En anglais Domain Specific Language, un DSL est un langage dédié. En informatique, on distingue deux types de langages : les langages généralistes (General Purpose Languages) comme PL/1, Ada ou UML, et les langages dédiés (Domain Specific Languages ou DSL) comme Excel. 25 muséologie La muséologie est une science qui s applique à tout ce qui concerne les musées, leur histoire, leur mission et leur organisation. 8 méthode agile Les méthodes agiles sont des procédures de conception de logiciel qui se veulent plus pragmatiques que les méthodes traditionnelles. En impliquant au maximum le demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du besoin du client, et non des termes du contrat de développement. 12 récolement le récolement est l opération qui consiste à vérifier, sur pièce et sur place, à partir d un bien ou de son numéro d inventaire : la présence du bien dans les collections, sa localisation, l état du bien, son marquage, la conformité de l inscription à l inventaire avec le bien ainsi que, le cas échéant, avec les différentes sources documentaires, archives, dossiers d oeuvres, catalogues. 8 UML En anglais Unified Modeling Language (=language de modélisation unifié), UML est un langage graphique de modélisation des données et des traitements

35 Webographie Documentation Java de jbpm : javadoc/ Guide utilisateur de jbpm : index.html Document Java de jboss Drools : job/drools/lastsuccessfulbuild/artifact/trunk/target/javadocs/stable/ drools-api/index.html Guide utilisateur de jboss Drools : job/drools/lastsuccessfulbuild/artifact/trunk/target/docs/drools-expert/ html_single/index.html Documentation Nuxeo : html/ Tutoriel Latex : index.php 35

36 Annexe A Test guide Cette première annexe vous présente le guide utilisateur du premier composant de test : le composant JbpmUnit. Ce guide a été rédigé en anglais en raison de la portée générale de ce qui a été développé. En effet, ces composants ont pour vocation à être partagé de façon libre et large. 36

37 JbpmUnit guide Realized by Solaine DURPOIX. June 9, 2009

38 Contents 1 Tests presentation 39 2 Your work Tests methods implementation MockUser DefaultMockUser AbstractMethodBasedMockUser MockUsers creation : implementation of setupmockuser Loop tests configuration Business rules tests configuration Additional configuration Creation of a file test.handler.config.properties Replace a handler in the workflow List of Figures 1 Example of JUnit tests method MockUser management Implementation of the method SetUpMockUser A configuration example Example of tests class