Le méta modèle de scénario

La Figure 4.4 présente le méta modèle de scénario en utilisant les notations du diagramme de classes UML. Les concepts sont détaillés dans les sections suivantes. Le méta-modèle ci- dessous est défini avec la notation EMOF.

Figure Le méta-modèle de scénario prés la définition de scénario, action, b d’interaction et la notion de f interactions sont des actions atom Le lien est composé de entre la cl d'au moins une action (cardinalit tour composées de flux.

Le lien est décrit par entre la cla décrit par une seule action (la ca composées de plusieurs flux. Cep seule interaction. D’un autre côté flux d’interactions. Par conséque ni même entre plusieurs flux d’i 0..1 de Action vers Scénario). Les deux sous sections suivantes

3.2.2.1. Les interactions

Les interactions décrivent le com différents types tel que demande fourniture d'information, commun

re 4.4. Le méta-modèle de Scénario

résenté à la Figure 4.4 inclus les méta-classes ess , but, ressource, etc. Il met l’accent sur deux notio

flux. Les flux sont des actions complexes a omiques. Cette généralisation est exclusive.

classe Flux et la classe Action indique qu’un flux lité 1..*). De la même manière, les actions peuve

classe Scénario et la classe Action, montre qu’un cardinalité 1). Les actions décrivant un scénario

ependant, il n’est pas exclu qu'un scénario soit d ôté, une action fait partie d'une description de scé uent, les actions ne sont pas partagées entre plusie d’interactions au sein d'un même scénario (d’où

es détaillent les deux notions d’interaction et de flu

omportement des agents dans un scénario. Elles p de de service, fourniture de service, demande d unication d’une ressource physique, etc.

ssentielles pour tions : la notion alors que les

lux est composé vent être à leur

’un scénario est io sont souvent it décrit par une cénario ou d’un sieurs scénarios ù la cardinalité flux. s peuvent avoir d’information,

982 2

Par exemple, « Le client saisit la date de réservation souhaitée » et « Le résultat trouvé est

affiché au client », sont deux interactions représentant des échanges d’information entre agents.

Il est à noter que les phrases en langage naturel (LN) sont souvent ambiguës et incomplètes par rapport au modèle de scénario. Dans le cadre de l’approche L’Ecritoire [Tawbi01], l’interpréteur de LN et l’outil de vérification permettent de compléter et de lever les ambiguïtés de la description en langage naturel afin de respecter le modèle de scénario. Les agents d’une interaction sont modélisés par l’entité Agent. Dans les deux interactions de l’exemple ci-dessus, deux agents sont identifiés : client et application.

Chaque interaction possède une direction. Les deux liens de et à entre les deux entités

Interaction et Agent indiquent qu’une interaction est dirigée d’un agent à un autre. Par exemple, l’interaction « le client saisit la date de réservation souhaité », est dirigée de l’agent client à l’agent application.

A noter qu’une interaction peut comprendre un seul agent, c’est le cas dans l’interaction : « la

période de réservation est vérifiée », où l’application est l’agent de et à de la même interaction.

La Figure 4.1 montre qu’un agent dans un scénario est source ou destination d'au moins une interaction. Un agent qui ne participe à aucune interaction n’a aucune raison de figurer dans le modèle de scénario.

Une interaction met en jeu une ou plusieurs ressources. Le paramètre dans une interaction est la ressource échangée entre les agents du scénario. Ceci est modélisé par la relation paramètre entre les deux entités Interaction et Ressource. Les ressources sur lesquelles les actions sont appliquées sont généralement de nature informationnelle mais peuvent également représenter des objets physiques lorsque le système à développer est un système automatique. Par exemple dans l’interaction « le client saisit la date de réservation souhaitée », la ressource est

date de réservation.

Comme le montre la Figure 4.1, trois types d’interactions sont identifiés : actions internes,

communications et communications utilisateur.

Les actions internes représentent une activité locale à un agent. Dans ce cas précis l’agent de et l’agent à sont identiques. Par exemple dans l’action interne « la période de réservation est

vérifiée », l’action de vérification est réalisée par le système de réservation et la ressource manipulée est la période de réservation.

Toutes les interactions qui ne sont pas des actions internes représentent des activités de communication entre deux agents distincts. Les activités de communication faisant participer un agent humain sont considérées comme des communications utilisateur. Les deux premiers exemples d’interaction sont des exemples de communication utilisateur car elles sont associées à l’agent Client.

Les interactions qui ne sont pas des communications utilisateur sont considérées dans le modèle comme des communications car elles sont associées à deux agents de type système. Par exemple dans l’action de communication « le système de réservation envoie une demande

de réservation à l’hôtel » le système de réservation et l’hôtel représente respectivement l’agent source et cible ; la demande de réservation représente la ressource échangée.

3.2.2.2. La notion de flux

Les flux permettent de définir l’ordonnancement entre les interactions dans un scénario. Les flux sont classés en quatre types : séquence, concurrence, répétition et condition. Ces quatre types sont modélisés à la Figure 4. et sont détaillés dans les sections suivantes.

• La séquence

Une séquence est composée de deux actions, la deuxième action se déroule suite à la première. La proposition « Le client saisit la date de réservation souhaitée et le résultat

trouvé est affiché au client » est un exemple de deux interactions en séquence. Etant donné qu'une action peut être composée de plusieurs actions, une séquence qui est une spécialisation d’actions peut être composée de plusieurs flux qui, à leur tour, peuvent appartenir à n’importe quel type de flux. Par contre, une séquence est toujours composée de deux actions au maximum. Par conséquent, une composition récursive de plusieurs séquences est utilisée pour exprimer le séquencement entre plusieurs interactions. Prenons l’exemple suivant: « Le client

confirme les données bancaires. L’agence de voyage confirme la réservation de vol à la compagnie aérienne et elle envoie les données bancaires à la banque ». Cette séquence est composée de manière récursive de l’interaction : « Le client confirme les données bancaires », qui se trouve en séquence avec le flux de concurrence composé de deux interactions : « L’agence de voyage confirme la réservation de vol à la compagnie aérienne et elle envoie

les données bancaires à la banque ».

Le même raisonnement s’applique aux quatre types de flux. Ainsi, une séquence peut être composée soit de contraintes, soit de concurrences, soit de répétitions ou de séquences d’actions.

ABB2 2

• La concurrence

Contrairement à une séquence, il n’y a aucun ordre spécifique entre deux actions concurrentes. Deux actions en concurrence ne commencent pas et ne se terminent pas nécessairement au même moment. Il est vrai que, du point de vue utilisateur, elles se déroulent au même instant mais ceci n’est pas nécessairement le cas du point de vue temporel. Prenons l’exemple suivant: « L’agence de voyage envoie une demande de réservation de vol à

la compagnie et de chambres à l’hôtel ». Cette phrase se reformule dans le modèle de scénario par deux propositions concurrentes où « l’agence de voyage envoie la demande de

vol à la compagnie aérienne et l’agence de voyage envoie la demande de chambres à

l’hôtel ». Ces deux interactions n’ont pas d’ordre spécifique, et du point de vue temporel, elles ne commencent ni ne se terminent au même moment. Cependant, du point de vue utilisateur, elles se déroulent en même temps et deviennent donc, selon la définition d’un scénario, concurrentes.

Une concurrence est composée de deux actions. Comme dans une séquence, on peut exprimer la concurrence entre deux flux d’actions complexes, tels que deux séquences d’interactions en concurrence.

Contrairement à la séquence et à la concurrence, la contrainte et la répétition sont basées sur une condition de flux. Nous détaillons ces deux notions dans les deux sous-sections suivantes.

• La condition de flux

La condition de flux exprime les conditions nécessaires pour décrire un enchaînement spécifique d’actions dans un scénario. La condition de flux est associée à la contrainte et à la répétition. Ainsi cette notion est modélisée par l’entité condition de flux qui est liée aux deux entités contrainte et répétition.

La Figure 4.4 montre qu’une répétition (respectivement une contrainte) est basée sur une condition de flux qui peut impliquer un à plusieurs objets du scénario. Prenons l’exemple :

« Si la période de réservation souhaitée est valide ». Cette condition de flux est attachée à une contrainte. Elle implique l’objet « La période de réservation souhaitée ».

• La contrainte

Une contrainte décrit les conditions nécessaires au déroulement de l’ensemble des actions qui la suivent. Le flux de contrainte est différent du flux alternatif (if-then–else) permettant de décrire plusieurs comportements possibles dans le même scénario et qui ne fait pas partie de notre modèle. Rappelons que notre définition d’un scénario met l’accent sur le fait que celui- ci décrit ‘un comportement possible’. Par conséquent, les contraintes dans un scénario limitent la description à celle d’un comportement unique.

Prenons l’exemple du scénario ‘Effectuer une demande de réservation via l’application en

vérifiant les disponibilités’. Ce scénario commence comme suit : « le client effectue une

demande de réservation, la période de réservation est vérifiée. Si la période est valide. L’application affiche une page au client proposant les disponibilités. Le client choisit …… ».

Ce scénario inclut une contrainte correspondant à la condition de flux « Si la période de

réservation est valide ». Le reste du scénario décrit un comportement unique correspondant au cas où la période de réservation est valide.

• La répétition

La répétition permet d’exprimer les flux d’actions qui se répètent plusieurs fois dans un scénario. La répétition doit définir le nombre exact de fois où ses actions peuvent se répéter. Prenons l’exemple « Au plus trois fois et jusqu’à ce que le numéro de la carte soit valide,

l’application affiche un message confirmant le paiement de la réservation ». Les interactions de ce flux peuvent se répéter au maximum trois fois.

Comme les autres types de flux, une répétition peut être composée d’une combinaison d’actions. Cela est exprimé dans l’exemple ci-dessus où le flux de répétition est composé de trois interactions correspondant à « l’application affiche un message confirmant le paiement

de la réservation ».

Dans le document MeTSI : Une Méthode de Transformation des Services Intentionnels (Page 97-102)