Point de vue fonctionnel

Les éléments de notre méta-modèle (fig. 8.3) qui composent ce point de vue sont décrits par le schéma ci-dessous.

L’application au cas d’école conduit au diagramme de classe de la figure 8.5. Pour plus de clarté, nous n’avons représenté qu’une partie de ce diagramme de classe. Nous utilisons les stéréotypes d’UML pour apporter de la sémantique aux classes et faire plus facilement le rapprochement entre les classes de ce modèle et celles du méta-modèle.

Chacune des classes processus possède ses propres attributs et opérations. Nous avons rensei- gné les informations concernant :

– le niveau du processus métier « commande » suivant un horizon et une période. Dans ce cas, nous l’avons placé en temps réel. Dans le cas d’un processus métier « gestion du carnet de commande », nous aurions pu avoir un horizon d’un mois et une période d’une semaine, par exemple.

– les contraintes et les objectifs de ce processus sont exprimés par la classe LiaisonTemps- Cycle de type « Liaison » exprimant la contrainte que la commande doit être terminée en deux jours.

Dans la littérature, différents auteurs ont déjà travaillé sur la représentation des processus en utilisant le formalisme UML. Nasser Kettani et al. (1999) proposent d’identifier les proces- sus aux cas d’utilisation, puis de compléter par des diagrammes de comportement. D’autres

Fig. 8.4 – Méta-modèle partiel - point de vue fonctionnel

!"

114 CHAPITRE 8. UTILISATION D’UML POUR LA MODÉLISATION D’ENTREPRISE

auteurs, Chantal Morley et al. (2000) modélisent les processus à l’aide des diagrammes de classes et des diagrammes de comportement. En fait, pour ces derniers auteurs, le cas d’uti- lisation se situe à un niveau supérieur, intitulé workflow, qui se concentre sur les activités de communication et de collaboration entre acteurs.

Nous pensons que la modélisation des processus doit effectivement faire appel à ces deux formes de contribution. Sur la figure 8.6, nous utilisons le diagramme des cas d’utilisation pour représenter les domaines de l’entreprise en tant que paquetages UML, et les processus domaine de l’entreprise en tant que cas d’utilisation UML. Les relations entre différents cas d’utilisation permettent de représenter la communication entre les processus, alors que les relations entre les paquetages expriment les dépendances entre les domaines. Cette dépendance sera utile lors du déploiement de la solution pour assurer une cohérence au niveau des domaines déployés dans l’entreprise.

Fig. 8.6 – Cadre de description des processus domaine

Nous traduisons ce choix de représentation sur notre cas d’école (fig. 8.7). Il y a un domaine avec deux processus domaine.

Fig. 8.7 – Représentation des processus domaine avec les cas d’utilisation

Dans la modélisation UML, les cas d’utilisation (« processus domaine ») appartiennent donc à des paquetages et ces éléments seront caractérisés uniquement par leurs noms.

Il est possible d’affiner les cas d’utilisation pour préciser les différents processus métiers ou activités qui les composent. Ces deux autres éléments du méta-modèle (processus métiers et activités) seront aussi représentés dans le diagramme d’activités, mais en utilisant la notion de stéréotype UML pour les marquer. Le diagramme d’activité est un des diagrammes de comportement. Il permet de définir les scénarios d’enchaînement des processus et des activités qui vont être exécutés avec :

– la description de l’enchaînement des processus métiers, – la mise en évidence des étapes de validation,

– la représentation des activités détaillant le déroulement du processus métiers,

– la représentation de la logique d’enchaînement en utilisant des opérateurs logiques du langage,

– le lien avec des objets d’entreprise, instanciés à partir des classes du modèle,

– l’utilisation des opérateurs d’émission et de réception de message permettant la repré- sentation d’un workflow.

La figure suivante est un diagramme de ce type. Les points représentent les événements de déclenchement du processus (ici plusieurs points d’entrée). Dans les cadres sont indiqués les processus métier qui sont mis à exécution avec leur intitulé précédé par le stéréotype. Les objets qui sont portés sur la gauche (commande, client, produit) correspondent aux informations en entrée et sortie d’un processus. Les flèches qui relient les objets au processus sont différentes de celles qui décrivent la logique d’enchaînement. On retrouve à ce niveau, sous une forme peu explicite si on la compare à un diagramme IDEF0, une logique de flux d’information. Enfin, comme dans un organigramme classique, les tests sont représentés par des losanges exprimant un branchement conditionnel.

! "

Fig. 8.8 – Représentation comportementale du processus domaine « Vente » par un diagramme d’activités

116 CHAPITRE 8. UTILISATION D’UML POUR LA MODÉLISATION D’ENTREPRISE

tivités qui composent un processus métier. Par ce moyen, la représentation prend un caractère hiérarchique : chaque description de comportement est associée à l’objet d’entreprise ou au processus qui en est la source. Ci-dessous, nous illustrons plus en détail le comportement du processus métier « commande de vente » à partir de certaines des activités avec lesquelles il possède une relation (fig. 8.5).

Fig. 8.9 – Enchaînement des activités pour le processus métier « Commande de vente » Nous pouvons aussi décrire les différents états représentatifs des activités de l’entreprise. Chaque processus ou activité du système se trouve dans une situation particulière à un ins- tant donné. Nous représentons ce point de vue en utilisant un diagramme d’états-transitions (fig. 8.10) qui permettra de décrire l’évolution d’une instance de classe (évolution d’état d’un objet en termes de comportement et de réaction à divers événements internes ou externes). Cette représentation est inspirée des travaux de normalisation menés par le WFMC1.

Fig. 8.10 – État d’un processus ou d’une activité

Cette représentation permet d’obtenir une trace de l’état de tous les processus et activités de

l’entreprise. À partir de ces traces, nous pouvons effectuer les traitements permettant d’obtenir des tableaux de bords sur l’état des processus.