CHAPITRE 5 : DU SERVICE OPERATIONNEL AU SERVICE LOGICIEL
2. La liaison entre le modèle opérationnel de service et le modèle d’implémentation de
2.2. Construction du modèle d’implémentation du service interactif
2.2.1. Le méta-modèle de la vue Interface Utilisateur
l’aide des interfaces graphiques. affiché à l’écran, c’est-à-dire le détails de leur aspect comme la c
La vue Interface Utilisateur cor première tâche est de présenter le seconde tâche est de recevoir tou entrée, boutons, …). Ces différen
Utilisateur n'effectue aucun traite effectués par le modèle. Plusie afficher des informations d'un l'utilisateur de changer de vue. Différents concepts sont définis d’eux. Notons que notre méta-m WSRP qui sont conforme aux b architecturaux.
Le méta-modèle de la vue Interfa
Figure 5.4. : Le m
e la vue Interface Utilisateur
st une application qui gère les interactions avec es. Elle est celle qui a la responsabilité de génér le positionnement des composants graphiques
couleur.
orrespond à l'interface avec laquelle l'utilisateur les résultats renvoyés par le modèle de la vue coo toutes les actions de l'utilisateur (clic de souris, sé rents événements sont envoyés au contrôleur. La
itement, elle se contente d'afficher les résultats de sieurs vues Interface Utilisateur, partielles ou
n même modèle. La vue peut aussi offrir la
is dans la figure 5.4. Nous donnons une définiti modèle ci-dessous est beaucoup spécifique à besoins de l’utilisateur final exprimés au traver
face Utilisateur est décrit à la figure 5.4.
e méta-modèle de la vue Interface Utilisateur
A382 c l’utilisateur à nérer ce qui est s ainsi que les
ur interagit. Sa oordination. Sa sélection d'une a vue Interface des traitements u non, peuvent la possibilité à ition de chacun à la plateforme ers les facettes
Le méta-modèle de la vue interface utilisateur se fait dans la spécification EMOF (Essentiel MOF) qui est défini selon le standard MOF [EMOF 2004]. Pour la spécification des méta- modèles invoqués, nous proposons d’utiliser l’outil Eclipse UML2Tool [UML2Tool], lequel permet de fournir la génération automatique des méta-modèles EMF à partir des méta- modèles UML2 définis. EMF est le « Framework Modeling Eclipse » qui est basé sur la spécification EMOF. Le méta-modèle de la vue Interface Utilisateur de la Vue Interface défini un certain nombre d’éléments qui sont défini ci-dessous :
VueIHM représente un écran web utile pour acquérir les interactions utilisateurs de type
entrée et sortie. Cet écran correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, …). Ces différents événements sont envoyés au contrôleur. L’objet VueIHM n'effectue aucun traitement, elle se contente d'afficher les résultats des traitements effectués par le modèle. Plusieurs écrans peuvent afficher des informations d'un même modèle.
Composant : Un objet composant est un objet qui permet de définir le décor d’un objet de type vueIHM qui est visible à l’utilisateur et lui permet d’interagir. Ce sont des éléments configurables et réutilisables qui composent les interfaces utilisateur de l’objet application. On distingue 2 types de composants : les conteneurs et les atomiques.
Les conteneurs : Un conteneur est un objet de type composant qui a comme fonction de regrouper d’autres composants graphiques atomiques ou conteneurs, en d’autre terme c’est une hiérarchie de composition d’objets graphiques. L’application propose des conteneurs tels que les formulaires.
Les atomiques : Ce sont les divers objets graphiques usuels et non décomposables d'une interface graphique qui sont visibles à l’utilisateur. Nous en citons quelques uns :
2 Command : objet graphique qui permet de réaliser une action qui lève un événement. 2 Graphic : objet graphique qui représente une image.
2 Input : objet graphique qui permet de saisir des données 2 Output : objet graphique qui permet d'afficher des données
2 SelectItem : objet graphique qui représente un élément sélectionné parmi un ensemble d'éléments.
2 SelectItems : objet graphique qui représente un ensemble d'éléments
2 SelectBoolean : objet graphique qui permet de sélectionner parmi deux états.
2 SelectMany : objet graphique qui permet de sélectionner plusieurs éléments parmi un ensemble
A4B2 2
2 SelectOne : objet graphique qui permet de sélectionner un seul élément parmi un ensemble.
Règle de Navigation : Les règles de navigation permettent de décrire comment les écrans décrits par des objets de type vueIHM s’enchainent entre eux en fonction des traitements. Une règle de navigation expliquent quels sont les éléments logiciels à exécuter pour répondre à un événement (requête web) déclenché à partir d’un écran (lien « de »).
L’application logicielle ServiceLogicielInteractif comprend un ensemble de vueIHM dans lequel l’utilisateur navigue en fonction des cas applicatifs et de ses interactions. Chaque requête http généré à partir des écrans de l’application est appelé un événement. Chaque
événement fait l’objet d’une règle de navigation permettant de décrire les éléments logiciels à exécuter pour traiter cette requête et répondre à l’utilisateur.
Les règles de navigation sont de plusieurs types en fonction de la complexité des éléments logiciels à assembler pour répondre à l’événement. Une règle de type E-V (Evénement – Vue) permet de stipuler que lorsque l’événement survient, la réponse consiste à exécuter l’objet de type vueIHM référencé par le lien « vers ». La règle de navigation consiste alors à passer d’un écran à l’autre sans effectuer de traitement applicatif.
Une règle de navigation de type E-C-V qui signifie Evénement-Contrôleur-Vue. La règle E- C-V spécifie que la réponse à l’événement est d’abord constituer par l’exécution du traitement applicatif à travers un élément logiciel de type contrôleur (lien entre règle et contrôleur) et ensuite l’écran a affiché est déterminer en fonction du cas applicatif obtenu par l’exécution du contrôleur (objet de type « forward »). L’élément de type contrôleur matérialise le traitement applicatif qu’il faut exécuter pour répondre à l’événement. Le traitement exécuté par le contrôleur consiste à invoquer une fonction d’orchestration qui appartient à la partie « Vue Coordination » du service_logiciel_interactif. Le contrôleur récupère de la VueIHM les données fournies par l’utilisateur et les passe à la fonction d’orchestration. Le résultat de la fonction d’orchestration est transmis au contrôleur. Celui-ci interprète le résultat afin de préparer leur affichage. En effet, ces données seront passées à l’élément de type VueIHM pour être affichées à l’utilisateur.
En résumé, la règle de navigation E-C-V représente un traitement applicatif qui donne lieu à un aiguillage sur plusieurs chemins de navigation (« forward ») alors que la règle E-V correspond simplement à un chemin de navigation.
Il existe deux types d’élément de type « forward » : celui qui représente comme prochain élément logiciel directement une vueIHM (« ViewForward ») et celui qui nécessite un traitement applicatif avant d’afficher la vueIHM à l’utilisateur (« EventForward »).
L’objet contrôleur permet de faire le pont entre la « vue Interface Utilisateur » et la « vue Coordination ». Il analyse la requête du client et se contente d'appeler le modèle adéquat et de renvoyer la vue correspondante à la demande. Une application logicielle
ServiceLogicielInteractif utilise généralement plusieurs objets contrôleurs dans une application. Le traitement du contrôleur consiste à récupérer les données de la requête de l’utilisateur (entrées). Ces données servent de ressources pour le processus d’orchestration (fonction d’orchestration) de la « vue coordination ». Ensuite, le contrôleur récupère le résultat de la fonction d’orchestration, ces données représentent souvent les sorties du contrôleur car elles vont être passées à la vueIHM pour être affichée.
Les données de type entrées ou sorties sont décrites par un type de donnée exprimé par un schéma de données XML (XSD).
La partie « Vue interface utilisateur » permet de spécifier les différents éléments logiciels qui rentrent dans l’implémentation de la partie interactive du service logiciel. La section suivante décrit la partie orchestration.