Couche acteurs

Au niveau de la couche acteurs, un premier raffinement est appliqu´e au dia-gramme BPD de la couche domaine. Il consiste d’abord `a identifier les diff´erents acteurs impliqu´es mettant en ´evidence leurs rˆoles respectifs. Il consiste ensuite `a d´etailler les fonctionnalit´es pour chaque acteur. Le choix du niveau de d´etail d´epend du besoin de l’utilisateur (le concepteur). Un acteur est d´efini comme une entit´e “physiquement” s´epar´ee interagissant avec d’autres entit´es `a travers une (ou

plu-Sélection

Produit ^{Paiement Livraison}

Hotel Search

+

Positioning ^Facilities _Search

Itinerary Translation ^Voice Synthesizer

Itinerary Translation _Synthesizer ^Voice Positioning ^Facilities _Search Hotel Search

+

sieurs) application(s) commune(s). Par ce fait, `a chaque application nous associons un groupe d’acteurs, par exemple le groupe <acheteur - vendeur - livreur - centre de paiement> ou le groupe <patient - m´edecin - pharmacien - s´ecurit´e sociale> ou le groupe <´Etat - Citoyen - Administration> etc. Le but du raffinement par ac-teurs est d’identifier `a travers l’illustration des ´echanges de messages les rˆoles des diff´erents acteurs afin de s´electionner la perspective `a partir de laquelle l’application sera raffin´ee davantage et impl´ement´ee par la suite.

La figure 3.13 illustre un exemple du premier niveau de raffinement de l’applica-tion d´ecrite par la figure 3.12. En effet, elle d´etaille les activit´es `a accomplir lors d’une ex´ecution de l’application d’achat en ligne mettant en ´evidence les acteurs suivants : l’acheteur ou l’utilisateur, le vendeur et le livreur. En plus du raffinement fonction-nel, la figure 3.13 illustre l’´echange de messages entre ces diff´erents acteurs. Cette description des diff´erents acteurs permet de mettre en avant diff´erents points de vue de la mˆeme application. De plus, elle souligne la nature distribu´ee de l’application illustr´ee par les ´echanges de messages d´ecrits.

L’application d´ecrite par la figure 3.13 illustre le rˆole des acteurs impliqu´es en d´etaillant les activit´es accomplies par chacun. Tout d’abord l’interaction commence entre l’acheteur et le vendeur. En effet, l’acheteur envoie un message au vendeur demandant un catalogue. Cet dernier renvoie les informations n´ecessaires dans un message correspondant. L’acheteur, apr`es s´election du (des) produit(s) d´esir´e(s), envoie un ordre d’achat au vendeur qui r´epond par un ordre de paiement. Apr`es r´eception du paiement, le vendeur entre en contact avec un livreur lui envoyant un message contenant la demande de livraison. Le livreur confirme au vendeur la livrai-son et entame l’envoi. Apr`es r´eception du message de confirmation de la livrailivrai-son, le rˆole du vendeur dans cette interaction prend fin. L’ex´ecution du processus m´etier de l’application d’achat s’ach`eve une fois que l’acheteur re¸coit ses produits.

La figure 3.13 met en ´evidence, `a titre illustratif, six exemples de correspon-dances entre des activit´es m´etiers et des op´erations abstraites propos´ees par les services abstraits de l’´ecosyst`eme, `a savoir, Recevoir Demande Catalogue, Envoyer

!"#$%& '()*+ ,(-.()*+ /$0* ()*+ Envoyer Demande Catalogue Recevoir

Demande Catalogue Catalogue ^Envoyer Recevoir

Catalogue Ordre d'Achat ^Envoyer

Recevoir

Ordre d'Achat ^{Recevoir Paiement}

Envoyer Paiement Envoyer Demande Livraison Recevoir Demande Livraison Envoyer Confirmation Livraison Recevoir Confirmation Livraison + Recevoir Livraison Envoyer Livraison + ,(-.()*+ ,(-'( + 1(* 0$2(%+3 4, 4+ 5&2')* &"6-+ Recevoir

Demande Catalogue Catalogue ^Envoyer

Recevoir Ordre d'Achat

Envoyer

Ordre Paiement Paiement ^Recevoir

Envoyer

Demande Livraison Confirmation Livraison ^Recevoir

,(-.()*+ ,(-'( + 1(* 0$2(%+3 4, 4+ 5&2')* &"6-+ Vente.Catalogue Vente.OrdreAchat Facturation.Paiement Envoyer Livraison

Demande ^{Recevoir Livraison} Confirmation Figure 3.13: Diff´erents acteurs d’une application d’achat en ligne

Catalogue, Recevoir Ordre d’Achat, Envoyer Demande Livraison, Recevoir Confirma-tion Livraison, Envoyer Livraison. L’identificaConfirma-tion des activit´e abstraites implique qu’elles ne seront plus raffin´ees dans les ´etapes suivantes. Nous soulignons l’activit´e Envoyer Livraison qui correspond `a l’acteur fournisseur et qui constitue un exemple d’une op´eration abstraite pouvant avoir des impl´ementations concr`etes o`u les acti-vit´es repr´esentent des tˆaches manuelles n´ecessitant une intervention humaine comme discut´e dans les sections 3.2.2 et 3.2.4.2.

Le raffinement par acteurs fournit un mod`ele de description applicative illus-trant une vision globale de l’interaction entre deux ou plusieurs acteurs (partici-pants). Cette vision est d´ecrite `a travers les s´equences d’´echanges de donn´ees. Cela rappelle le mod`ele de chor´egraphie entre services web WS-CDL [145]. En effet, la chor´egraphie de services est d´efinie par Peltz comme une description collaborative o`u chaque participant pr´esente le rˆole qu’il joue dans l’interaction [114]. Elle met en ´evidence les s´equences de messages impliquant plusieurs entit´es afin d’illustrer le comportement de plusieurs syst`emes interagissant. Elle donne une vue du com-portement externe visible. Par analogie, la couche acteurs fournit un raffinement du mod`ele d’interaction `a travers une chor´egraphie entre les diff´erents acteurs.

D’autre ´el´ements de repr´esentation BPMN sont utiles `a ce niveau. L’´el´ement gra-phique pool (bassin) de la cat´egorie swimlane de BPMN est utilis´e pour s´eparer les vues des diff´erents acteurs. De la cat´egorie objets de connexion nous retenons le flux de messages. Il est repr´esent´e par une fl`eche en pointill´es. Il d´esigne un ´echange de messages entre deux entit´es s´epar´ees du processus notamment deux acteurs. Contrai-rement au flux s´equentiel, le flux de messages peut traverser les bordures d’un pool.

!"#$%& '()*+ ,(-.()*+ /$0* ()*+ Envoyer Demande Catalogue Recevoir

Demande Catalogue Catalogue ^Envoyer Recevoir Catalogue

Envoyer Ordre d'Achat

Recevoir

Ordre d'Achat Ordre Paiement ^Envoyer Recevoir Ordre Paiement Recevoir Paiement & Validation Confirmer Paiement Envoyer Dem.

Livraison ^{Recevoir Conf.} Livraison Recevoir Livraison

123*

&'

()*+ _{Recevoir Demande}

Authentification Ordre Paiement ^Recevoir Confirmation ^{Recevoir Envoyer Paiement} & Validation Envoyer Demande Authentification 123* &' ()*+ 4)'5(-"67 &"8-+ 9&7')* &"8-+ Recevoir Demande Authentification Envoyer Jeton Auth. Transférer à

Opérateur Principal ^Recevoir Auth. Ok

Envoyer Jeton Auth.

Recevoir

Ordre Paiement Confirmation ^Recevoir Validation ^Envoyer Paiement ^Envoyer Authentifier Recevoir Demande Livraison Envoyer Conf. Livraison + Envoyer Livraison +

Figure 3.14: Variante des diff´erents acteurs d’une application d’achat en ligne

La figure 3.14 illustre une variante plus d´etaill´ee du raffinement propos´e dans la figure 3.13. En effet la figure 3.13 d´ecrit trois acteurs tandis que la figure 3.14 introduit un acteur suppl´ementaire qui intervient dans l’interaction : l’op´erateur de t´el´ephonie mobile `a travers lequel l’acheteur est connect´e via son PDA. L’introduc-tion de ce nouvel acteur permet une vue (visibilit´e) plus large du domaine et par suite une application englobant de nouvelles fonctionnalit´es. Effectivement, la figure 3.14 d´ecrit l’´echange de messages avec l’op´erateur mettant en ´evidence le rˆole qu’il peut jouer dans l’authentification de l’utilisateur et l’´eventuel paiement. Nous pou-vons imaginer qu’un fournisseur de services de vente passent un contrat avec un ou plusieurs op´erateurs afin de publier ses services sur leurs r´eseaux. L’acheteur pourra alors effectuer le paiement par l’interm´ediaire de son op´erateur.

3.3.1.3 Couche m´etiers `

A ce niveau, partant de la mod´elisation du point de vue de chaque acteur du niveau sup´erieur, un raffinement par m´etier est conduit pour un acteur s´electionn´e. L’utilisateur (concepteur) choisit le point de vue de l’acteur qui lui convient afin de d´evelopper le processus m´etier de sa perspective. G´en´eralement, l’utilisateur assure le rˆole d’un des acteurs de l’application ´etudi´ee. Par exemple dans le cadre d’une application de gestion de voyages, si l’utilisateur de cette d´emarche est le client qui cherche `a composer son itin´eraire, ce dernier d´ecrira le processus m´etier et les ´echanges de messages correspondant `a son point de vue. Cependant si l’utilisateur