Phase 2: Identification des services par acteur

La phase «Identification des services par acteur» a pour objectif principal la transformation les exigences métiers capturées à travers les modèles des cas d‟utilisation en une collection de services. Il s‟agit principalement d‟identifier les services candidats à partir des modèles des cas d‟utilisation associés à chaque acteur.

L‟artefact clé de cette phase est un ensemble de PIMs associés aux différents acteurs du système. Chaque PIM se compose des différents services permettant de réaliser les besoins d‟un acteur spécifique. L‟identification des services se fait en adoptant des règles de refactoring. En effet, Kim et al. (Kim et al., 2007) ont défini plusieurs règles de refactoring permettant

l‟identification des services à partir des modèles de cas d‟utilisation. Chaque cas d‟utilisation est décomposé en termes d‟un ensemble de tâches permettant la réalisation des besoins des acteurs qui sont en interaction avec ce cas d‟utilisation. Chaque tâche est définie comme étant une unité de travail indivisible apportant une valeur ajoutée à l‟utilisateur dans le contexte d‟un processus métier. Une tâche fait partie des scénarios permettant de réaliser les cas d‟utilisation. Dans cette phase, un ensemble de tâches sont créés à partir des diagrammes des cas d‟utilisation pour chaque acteur. Cette phase peut être formalisée en se basant principalement sur les diagrammes de séquences définis en UML qui jouent un rôle fondamental pour la représentation des différents scénarios des cas d‟utilisation.

Le refactoring des cas d‟utilisation est la redistribution des comportements en termes de tâches d‟un cas d‟utilisation à un autre. A partir des tâches des différents cas d‟utilisation, et en appliquant les règles de refactoring, nous pouvons identifier des cas d‟utilisation bien adaptés.

Kim et al. (Kim et al., 2006) identifient cinq règles de refactoring : la règle de refactoring par décomposition, la règle de refactoring par équivalence, la règle de refactoring par généralisation, la règle de refactoring par fusion et la règle de refactoring par suppression.

La règle de refactoring par décomposition est appliquée lorsque nous avons des cas d‟utilisation compliqués. Dans cette situation, il est nécessaire de faire décomposer ce cas d‟utilisation en des sous-cas d‟utilisation plus simples. Ceci est effectué en utilisant l‟ensemble des tâches associées à chaque cas d‟utilisation. En effet, pour chaque cas d‟utilisation, nous élaborons les tâches permettant de réaliser le cas d‟utilisation. A partir de ces tâches, nous pouvons déduire des fonctionnalités indépendantes et par conséquent, définir des sous-ensembles de tâches qui correspondent à des nouveaux cas d‟utilisations.

Le refactoring par équivalence s‟applique à des cas d‟utilisations ayant des tâches équivalentes. Dans ce cas, nous pouvons conclure que les deux cas d‟utilisations ont le même comportement et on peut les traiter comme un seul cas d‟utilisation correspondant à un seul service.

Le refactoring par généralisation peut s‟appliquer lorsque nous avons des cas d‟utilisation qui partagent des tâches communes. Dans ce cas, nous créons un cas d‟utilisation de base contenant les tâches communes ainsi que de nouveaux cas d‟utilisation étendant le cas d‟utilisation de base.

Le refactoring par fusion est appliqué lorsque nous avons des cas d‟utilisation de granularité fine qui modélisent des fonctionnalités sémantiquement reliées. Dans ce cas, nous fusionnons les deux cas d‟utilisation pour avoir un cas d‟utilisation plus consistant.

Le refactoring par suppression est défini lorsque nous avons un cas d‟utilisation qui n‟a aucune relation que ce soit avec les autres cas d‟utilisation ou avec les acteurs du système. Dans cette situation, le cas d‟utilisation est redondant et par conséquent on peut le supprimer du système.

Dans le cadre de notre étude de cas, nous avons identifié les cas d‟utilisation qui interagissent avec un acteur prédéfini. Nous décrivons chaque cas d‟utilisation par un ensemble de tâches, comme présenté dans la figure 80 pour le cas d‟utilisation « assurer Formation » associé à l‟acteur Enseignant. Pour chaque acteur (Etudiant, Enseignant, Administrateur), nous identifions les différents modèles métiers se composant des services correspondant et répondant aux besoins d‟un acteur donné.

Figure 80–Scénario associé au cas d’utilisation «assurer Formation» associé à l’acteur

Enseignant

T1. L‟enseignant consulte l‟agenda T2. L‟enseignant gére les forums T2.1 L‟enseignant consulte un forum T2.2 L‟enseignant recherche un forum donné T2.3 L‟enseignant poste un message dans un forum T3.l‟enseignant gère les tests

T3.1 l‟enseignant ajoute un test T3.2 L‟enseignant consulte un test T3.3 L‟enseignant propose une solution à un test T4. L‟enseignant gére les ateliers

T4.1 L‟enseignant peut consulter un atelier T4.2 L‟enseignant propose une solution à l’atelier T5.l‟enseignant gére les devoirs

T5.1 L‟Enseignant peut consulter un devoir T5.2 L‟Enseignant propose une solution à un devoir T6. L‟enseignant gérer la documentation d‟une formation.

T6.1 L‟enseignant peut consulter la documentation d‟une formation donnée T6.2 L‟enseignant ajoute la documentation d‟une fomation

T6.3 l‟enseignant supprime la documentation d‟une formation T7. L‟enseignant peut gérer les glossaires d‟une formation donnée T7.1 L‟enseignant consulte un glossaire

T7.2 L‟enseignant ajoute un article dans un glossaire T7.3 L‟enseignant recherche un article dans un glossaire T8. L‟enseignant participe dans les chats.

T8.1 L‟enseignant ajoute un chat T8.2 L‟enseignant modifie un chat T8.3 L‟enseignant participe à un chat T9.L‟enseignant gére les examens

T9.1 L‟enseignant consulte l‟agenda des examens T9.2 L‟enseignant propose le sujet de l‟examen T9.3 L‟enseignant corrige les copies de l‟examen

En ce qui concerne l‟acteur Enseignant, comme illustré dans la figure 81, le cas d‟utilisation «Assurer formations» est décomposé entre trois cas d‟utilisation «Documentation», «Examen», et «Formation». Chaque cas d‟utilisation est décrit par un ensemble de fonctionnalités indépendantes. Ainsi, chaque cas d‟utilisation devient un service. Au contraire, le cas d‟utilisation «Gestion de formations» est décrit par des fonctionnalités qui ont des relations avec le service « Formation». Dans ce cas, le service identifié sera fusionné avec le service Formation puisque les deux services fournissent des activités sémantiquement proches.

Figure 81–Identification des services associés à l’acteur « Enseignant »

La figure 82 montre les différents services qui composent le modèle de services correspondant à l‟acteur Administrateur. Pour cet acteur, le cas d‟utilisation Inscription est décrit avec des tâches indépendantes. Dans cette situation, ce cas d‟utilisation devient automatiquement un service. Au contraire, le cas d‟utilisation «Gestion de formations» est décomposé en de sous-cas d‟utilisation Agenda, Examen et Formation. Chaque cas d‟utilisation est décrit par un ensemble indépendant des fonctionnalités indépendantes. Ainsi, chaque cas d‟utilisation deviendra un service.

PIM-Enseignant

<<service>> Formation <<service>> Documentation

Figure 82–Identification des services associés à l’acteur «Administrateur»

Figure 83 illustre les différents services qui composent un modèle correspondant à l‟acteur Etudiant. Pour cet acteur, le cas d‟utilisation «Inscription» est décrit par des ensembles de tâches indépendantes. Ainsi, ce cas d‟utilisation devient un service. Au contraire, le cas d‟utilisation «Suivre formation» est décomposé en quatre cas d‟utilisations Agenda, Documentation, Examen et Formation. Chaque cas d‟utilisation est décrit par des fonctionnalités indépendantes. En conséquence, chaque cas d‟utilisation devient un service.

Figure 83–Identification des services associés à l’acteur «Etudiant »