Propriétés non-fonctionnelles : annotation des processus et gouvernance des services

Dans la littérature, bien que le terme « propriétés non-fonctionnelles » soit utilisé depuis plus de 25 ans et que la majorité ait souligné l’importance de l’utilisation de ces propriétés, il n’existe toujours pas un consensus pour les définir, les obtenir et les valider [Glinz, 2007]. Ce manque critique pour la réussite des processus et applications de l’entreprise est peut être dû à plusieurs facteurs ([Rosa et al., 2002] et [Khaled et al., 2005]) : Afin de combler ce manque et d’atteindre les besoins exprimés dans le chapitre I, nous avons présenté dans le chapitre II des solutions existantes pour la description, la modélisation et la gestion des propriétés non-fonctionnelles (pour les processus métier et pour les services). Nous nous sommes également intéressés à étudier les travaux existants autour : (i) de la gouvernance SOA pour une meilleure gestion et rationalisation des services, (ii) de la réconciliation et la sélection de services selon les propriétés non-fonctionnelles. Cependant, ces travaux présentaient certaines limites (vues dans le chapitre II) qui nous sont essentielles. Ces limites concernent les trois thèmes qui constituent notre étude :  modélisation des propriétés non-fonctionnelles et annotation des processus métier : il est nécessaire, lors de la phase de modélisation de processus, de permettre aux utilisateurs d’annoter facilement les activités par un ensemble de propriétés non-fonctionnelles. Cet ensemble de propriétés doit être assez large pour qu’ils puissent exprimer leurs besoins métier ;  rationalisation de la gestion des propriétés non-fonctionnelles par la gouvernance SOA : il est indispensable de gérer l’ensemble des propriétés non-fonctionnelles depuis la phase de la publication des descriptions de services. La gouvernance SOA adresse ce besoin en proposant des concepts visant la modélisation des descriptions de services et la prise en considération de leurs propriétés non-fonctionnelles ;

Dans le présent chapitre, comme l’illustre la Figure 23, nous nous intéressons aux deux premiers thèmes de notre problématique de recherche. Nous proposons, dans la Section III.2, un enrichissement de la modélisation graphique des processus métier collaboratifs BPMN 2.0 par l’annotation non-fonctionnelles des activités. Dans la section III.3, nous présentons un cadre permettant de gérer les services et les propriétés non-fonctionnelles au sein du registre de gouvernance SOA. Ce système se base sur des standards afin de garantir principalement l’interopérabilité (aspect essentiel dans un cadre collaboratif). Deux composants principaux constituent cette plateforme : (i) «Modélisation des processus » qui permet de modéliser les processus métier collaboratifs et se base sur l’outil de modélisation graphique existant Petals BPM et (ii) « Annotation non-fonctionnelle » qui assure l’annotation non- fonctionnelle des activités métier par des exigences non-fonctionnelles. Dans les sous-sections qui suivent nous détaillons ces deux composants.  Petals BPM est un modeleur graphique, open-source, en ligne de processus BPMN 2.04. Dans la Figure 25 nous représentons une capture d’écran de son interface graphique. Il est composé de trois parties : (i) la palette BPMN 2.0 (à gauche) contenant l’ensemble des éléments permettant aux utilisateurs de créer des processus BPMN 2.0, (ii) la zone de modélisation (au centre) qui permet aux utilisateurs de dessiner leurs processus grâce à la palette d’outils, et enfin (iii) la définition des  Comme nous venons de le voir, Petals BPM permet uniquement de décrire fonctionnellement les processus métier collaboratifs. Petals BPM – NFR enrichira la description interne de la palette graphique pour lier automatiquement la modélisation de l’activité BPMN 2.0 au composant « annotation non-fonctionnelle » que nous détaillons ci-après.

Nous avons souligné dans les chapitres précédents l’importance de la prise en compte des exigences non-fonctionnelles lors de la modélisation des processus métier. Nous avons également mis en évidence l’importance de l’utilisation des standards non seulement pour assurer l’interopérabilité dans ce contexte collaboratif, mais aussi pour l’étendue et l’intégration de nos travaux open-source. Ces deux besoins ont constitué notre point de départ pour la modélisation et l’annotation non- fonctionnelle des processus BPMN 2.0. Dans le chapitre état de l’art, nous avons étudié quelques modèles et approches existants (cf. sous-section II.5.4 et II.5.5) et nous avons déduit qu’aucun d’eux ne couvrait à la fois nos deux besoins. Pour répondre à cette problématique de recherche, nous avons réalisé un travail d’analyse de la littérature sur les exigences non-fonctionnelles qui peuvent potentiellement être définies au niveau métier. Nous effectuons une première analyse de la littérature sur ce sujet en nous basant sur les travaux présentant dans [Santos et al., 2010], [Cysneiros et al., 2004], [Mylopoulos et al., 1992], [Chung et al., 2000], [Rodriguez et al., 2007], [Chung et al., 2009], et [Heinrich et al., 2011]. Chacun de ces travaux fournit un ensemble d’exigences non-fonctionnelles proposé, en extrait, dans le Tableau 3 ci-après (cf. Annexe 2 pour le tableau complet). La dimension horizontale représente la liste des exigences non- fonctionnelles définies dans les travaux de recherche élaborés par les auteurs. Même si les auteurs se différencient sur quelques exigences, nous remarquons que les exigences suivantes : « disponibilité », « prix», « temps de réponse », « sécurité », « exactitude (Accuracy)» et « intégrité » sont majoritairement présentes dans tous les travaux. À l’exception de l’exactitude, nous constatons que ces exigences sont également présentes dans le standard WSQF. Nous effectuons une deuxième analyse représentée dans le Tableau 3 (cf. Annexe 2 pour le tableau complet) par la dimension verticale.