Diagramme d’activité UML

UML [OMG09] est un langage de modélisation maintenu par l’OMG qui s’est stan-dardisé de par sa position dominante dans l’industrie du logiciel. UML est un langage

2.4. Modélisation de processus métier 41 polyvalent permettant de modéliser un système selon différents points de vue. Le point de vue statique ou structurel représente la structure statique du système en utili-sant des objets, attributs, opérations et relations. Le diagramme de classe appartient à cette catégorie. Le point de vue dynamique ou comportemental représente le com-portement dynamique d’un système en montrant les interactions entre les objets ou les changements d’états au sein d’un objet. Les diagrammes d’états et d’activité font partie de cette catégorie.

Les différents diagrammes existant dans UML 2.0 sont organisées sous la forme d’un diagramme de classe dans la figure 2.8.

Diagram

Structure Diagram

Behaviour Diagram

Class Diagram ^Component Diagram Object Diagram Activity Diagram Use Case Diagram State Machine Diagram Composite Structure Diagram Deployment Diagram Package Diagram Interaction Diagram Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram

Figure2.8 – Diagrammes UML 2.0

Dans cette sous-section, nous nous intéressons particulière au diagramme d’activité qui est généralement utilisé pour le BPM. Il montre le flot d’exécution des différentes actions ainsi que le flux de données entre ces actions. Ces informations sont représentées graphiquement sous la forme d’actions caractérisés par des rectangles aux bords arrondis, liées entre elles afin de former un processus. La spécification du diagramme d’activité a beaucoup changé entre UML 1.x et UML 2.x. En effet, une variation du diagramme d’état (ou statechart) était utilisée dans UML 1.x. Un état représentait une action dont la terminaison était indiquée par une transition vers un autre état. Dans UML 2.x, le diagramme est désormais défini beaucoup plus précisément et basé sur la sémantique du réseau de Petri.

Pour la modélisation de la composition de services à l’aide du diagramme d’activité, l’exécution d’un service est généralement représentée par une action, c’est à dire une

étape de l’activité. La transition vers cette activité modélise alors l’appel au service et inversement celle en sortie indique la fin de l’exécution du service. Ce choix de modélisation a été utilisé pour la représentation de l’exemple de composition dans la figure 2.9.

(a) Scenario de composition (b) Diagramme d’activité

Figure2.9 – Exemple de modélisation UML pour la composition de service Une partie de la communauté de recherche a tenté d’étendre UML par altération de son métamodèle. Cette manière de procéder apporte beaucoup de flexibilité car il est ainsi possible d’apporter des changements profonds dans UML. Malheureusement, les modèles qui en résultent ne sont plus compatibles avec le métamodèle d’UML et ils ne peuvent donc pas être créés ou modifiés à l’aide des outils UML existants. Le langage obtenu n’est donc plus standard ni populaire. Un exemple d’une telle approche serait celle de Bendraou et al. qui a proposé UML4SPM dans [BGB05]. UML4SPM est un nouveau langage basé sur le diagramme d’activité UML 2.0 pour la modélisation de processus logiciels. Les auteurs ont également travaillé sur la génération de code BPEL à partir de leurs modèles [BSGB07]. Au lieu de modifier le métamodèle d’UML, l’OMG promouvoit l’utilisation de pro-fils [uml99]. Un profil est un ensemble de stéréotypes, de propriétés (tagged values) et de contraintes exprimées en OCL permettant de personnaliser UML, tout en restant compa-tible avec le métamodèle standard. Un stéréotype est représenté graphiquement par un nom encadré par des guillemets (ex : ≪stéréotype≫) et qui est placé au dessus du nom d’un autre élément. Les stéréotypes permettent de distinguer plusieurs sous-classes d’un même méta-élément. Les tagged values sont des propriétés associées à un stéréotype afin de permettre de stocker des informations supplémentaires, qui sont généralement spécifiques au domaine d’application (ex : les services Web). Ce chemin a été emprunté par Gardner

2.4. Modélisation de processus métier 43 et al. d’IBM UK qui ont présenté dans [AGGI03] un profil UML pour la modélisation de processus métier à l’aide du diagramme d’activité et une possibilité de conversion vers BPEL. Une adaptation de ce profil pour BPEL 1.1 a ensuite été implémentée par Mantel d’IBM UK2. Ces profil ne sont désormais plus à jour car ils sont basés sur UML 1.4 et BPEL 1.x. UML 2.x et BPEL 2.0 sont maintenant populaires et ceux-ci apportent de nombreux changements. Le profil d’IBM a été mis à jour plus tard par Ambühler [Amb05]. Cette nouvelle version prend en charge UML 2.0 mais reste malheureusement basée BPEL 1.1. Ceci est un problème important car le profil en question est une représentation directe et exhaustive de BPEL en UML. Ils obtiennent ainsi une représentation graphique exacte de BPEL. L’inconvénient de cette approche est que le profil est déprécié à chaque mise à jour de BPEL et il serait difficile de générer un autre langage que BPEL à partir des modèles réalisés. C’est la raison pour laquelle l’OMG conseille l’utilisation de modèles plus abstraits qui ne sont pas propres à un langage de programmation ou à une plateforme, en particulier pour les approches de type MDA [Sol00]. MDA est l’approche MDE la plus populaire actuellement.

D’autres auteurs ont présenté dans la littérature des profils UML qui ne sont pas spé-cifiques à un langage de programmation donné. Ceci résulte en la création de modèles plus abstraits dit PIM . Ces approches sont donc plus fidèles à MDA et présentent l’avan-tage d’utiliser des modèles moins complexes. A partir de ces modèles, il est possible de générer différents langages de programmation, éventuellement en passant par des modèles intermédiaires moins abstraits dit PSM . Ainsi en cas de mise à jour du langage de pro-grammation cible, seules les règles de transformation doivent être mises à jour et non les modèles eux-mêmes. Sur ce principe, Grønmo et al. ont amorcé un travail sur un profil UML 1.4 pour le développement de services Web composés en suivant les principes de MDA [GS04]. Ce travail a ensuite été continué par Skogan et al. dans [SGS04]. Ce profil n’est plus à jour car basé sur la version 1.4 d’UML. UML 2.x apporte de nombreux chan-gements fondamentaux qui affectent la solution proposée. Un profil similaire pour UML 2.0 a cependant été présenté par de Castro et al. dans [CMS06]. Les auteurs ont cependant indiqué que le modèle n’était pas assez expressif pour permettre la génération de code de manière automatique. Nous presenterons notre proposition de profil UML 2.0 dans le Chapitre 4. Nous avons introduit ce profil nommé UML-S ou UML pour les Services dans [DNsmGW08]. UML-S produit des modèles suffisamment précis pour permettre la génération de code tout en restant suffisamment générique pour pouvoir générer

rents langages de programmation. Des règles de transformation des diagrammes UML-S vers BPEL 2.0 ont été présentées dans [DGW08a] et utilisées dans le cadre d’une étude de cas [DGW08b]. UML-S est conçu pour fournir un bon compromis entre la clarté et l’expressivité tout en restant fidèle aux principes du MDA.