Participation à la création d'un produit technologique: l'assistant e-commerce( Télécharger le fichier original )par Roger Lemoine Université de Rennes 1 - Management informatique et commercial de la relation client fournisseur au national et à l'international 2012 |
(L'annexe 19 correspond à la version finale de la plaquette marketing). 3.2.6 Modélisation UML* de l'applicationDernière étape de notre stage, la modélisation UML*, va constituer le gros de notre travail dans l'entreprise Dialonics. UML* signifie « (en anglais Unified Modeling Langage ou « langage de modélisation unifié ») est un langage de modélisation graphique à base de pictogrammes. Il est apparu dans le monde du génie logiciel dans le cadre de la conception orientée objet. Couramment utilisé dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au domaine informatique. UML* est l'accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML* est à présent un standard défini par l'objet management Group (OMG) ». Source : Wikipédia. Pourquoi modéliser ? Ce qu'il faut savoir a propos de la modélisation : - Non, ce n'est pas le seul moyen de programmer. - Oui c'est un moyen de programmer sans taper la majeure partie du code.
Pour sa part Monsieur Panaget voit en la modélisation un certain formalisme, un moyen de façonner un plan de travail. Elle facilite ainsi la reprise de l'existant par une autre équipe, elle permet de prioriser les tâches, d'éviter « l'enlisement » et génère un gain de temps dans un travail qui porte sur des milliers de lignes de code. Il faut savoir qu'il y a une vraie bataille d'opinion la concernant. Il y a les « pour » et les « contre ». A vrai dire si la nuance était si simple, il y a longtemps que la normalisation aurait tranché ! Déploiement : Monsieur Panaget a réalisé l'implémentation sur notre ordinateur du logiciel Entreprise Architecte pour la modélisation et l'environnement Eclipse pour le codage. Les logiciels sont maintenant implémentés dans notre système, les accès sont ouverts sur le serveur Lettre Z:\\marduk afin de réaliser des sauvegardes avec le logiciel TortoiseSVN. Pendant cette période, notre travail consistait à poser des pictogrammes dans une feuille de modélisation de façon à générer du code, pour au final faire converser l'agent virtuel avec l'internaute. Remarque : Il est important de souligner que nous n'avons pas la prétention d'expliquer toutes les fonctionnalités du logiciel. Nous tenterons donc ici une approche explicative. Précisons enfin que les logiciels sont en anglais. Ci-dessous l'interface du logiciel de sauvegarde : SVNtortoise
a) Logiciel Entreprise Architecte : Présentation générale : Le logiciel est scindé en deux fenêtres : A gauche : l'arborescence du développement, à droite : la fenêtre de modélisation
Sous entreprise Architecte: Le fichier « Dialoguing Agent » agent dialoguant est caractérisé par une icône. (Partie de droite) Une icône correspond à un processus. Rappelons-nous des Processus du modèle relationnel : (livrable numéro 1) A : Le processus Achat B : Les Engagements de l'E-commerçant C : Le site D : La vente du PAP E : Les processus métiers A chaque processus est associée une icône :
Voici le schéma de base, les autres processus viendront se positionner a côté de l'agent dialoguant Processus Achat. Voici la même fenêtre 1 mois plus tard Liste des processus Ce symbole désigne une fenêtre de dialogue
Pour que la boîte puisse s'ouvrir sur un traitement il faut la déclarer, pour cela faire un clic droit puis « Advanced » et « make composite ». Ainsi quand on clique dans une fenêtre de dialogue, une autre fenêtre s'ouvre. Ci-dessous la fenêtre de dialogue : Processus achat avec les différents thèmes du processus achat. Figure 1 : En cliquant sur une boîte de dialogue, on ouvre la fenêtre suivante : (dans laquelle nous bâtissons notre nouvelle application) Description de la figure 1 :
Cette icône est une (( not understood )) qui traduit une non compréhension de la question de l'internaute par le système. On trouvera en réponse un autre (( output behavior )). Si le système ne comprend pas la question posée elle sera associée au (( not understood )) (icône rouge) la réponse formulée sera alors différente, dans ce cas : (( Je n'ai pas compris...Merci de reformuler ))
Dans la figure 1 on voit que: soit le système comprend et demande une précision. (Il va canaliser l'internaute vers un sous-thème), soit il ne comprend pas et suggère une reformulation. Figure1 (suite)
Ce dernier pictogramme caractérise une boîte de dialogue si le système identifie la question, il ouvre la boîte de dialogue suivante : La fenêtre suivante s'ouvre alors et va traiter la question « pourquoi s'inscrire ? » c'est elle qui va apporter la réponse à la question posée. (Figure2) Figure 2 : Description de la figure 2 :
Nous retrouvons ici un « Input Behavior », la question est posée par l'internaute (comportement d'entrée) Il arrive qu'une question n'ait pas de sens seul ! « Quelle est la raison ? ». On va ainsi lui allouer une
propriété dite de « scope local De ce fait la portée de l'énoncé de cette question va pouvoir se rattacher localement à la première question, et lui permettre dans ce cas de se rattacher a l'argument : « pourquoi faut-il s'inscrire ? ». Grâce à cette propriété le système va comprendre : « Quelle est la raison pour laquelle il faut s'inscrire ?» Un premier « output behavior » (réponse de la machine) va résumer la question de l'internaute.
Un deuxième output behavior va « pusher » (ouvrir) une page montrant le chemin dans l'arborescence de l'application.
Voici 2 nouvelles notions : « l'alternative et le call » Nous ne nous étendrons pas beaucoup plus sur les pictogrammes. Voici simplement deux nuances qui méritent d'être esquissées a ce stade c'est la notion :
L'alternative suggère qu'il y a plusieurs réponses possibles à la question posée. Le système prendra les pictogrammes dans l'ordre des numéros posés, à défaut s'il n'y a pas de numéros, les arguments vrais dans la feuille UML*, c'est-à-dire ceux qui répondent à une condition déclarée. Exemple : Si je déclare que pour passer une commande je dois payer, c'est un prédicat. Alors si le système rencontre cet argument dans la feuille, il le choisit prioritairement.
Dans ce cas à la question posée : « comment passer une commande ? » Il demandera
Puis l'alternative prendra la deuxième icône dans l'ordre des numéros de la feuille de modélisation. Ici, l'icône qui indique le chemin de la page de procédure « comment passer une commande ?».
Rappelons que pour passer une commande, il y a deux cas de figure : - Soit l'internaute est client, il dispose d'un compte sur le site. Dans ce cas, le système mémorise l'information et renvoi l'internaute à la procédure de commande.
- Soit l'internaute n'est pas encore client, le système mémorisera l'information et dirigera le prospect vers la procédure le concernant. - Le dialogue se ponctuera par un point de sortie, qui nous renvoie vers le masque précédent « le call étant traité » le système mettra en avant la procédure de passation de commande. Nous travaillons principalement sur les 2 premiers modèles (figure 1 et 2). Monsieur Panaget nous aide à conceptualiser les modèles plus élaborés. Au fur et à mesure que nous modélisons nos questions dans l'application UML* nous marquons en jaune les cellules dans Excel pour marquer notre avancée. 47 Dans l'interface gauche du logiciel Entreprise Architecte, cette icône correspond à une fenêtre vierge (Partie de droite) dans laquelle nous allons réaliser une nouvelle modélisation. C'est dans cette fenêtre que nous travaillerons la modélisation. On retrouve ici (à Gauche) les thèmes et les sous-thèmes développés dans notre fichier Excel. Il faut aussi retenir que toute suppression de pictogramme a gauche est définitive, la réciproque n'est pas systématiquement vraie à droite.
Monsieur Vincent Louis Docteur en l'informatique nous a conseillé une méthodologie de travail simple : Un premier masque sur l'identification de la question : Une deuxième étape qui apporte la réponse à la question posée. Nous sommes ainsi arrivés à une méthode plus accessible avec trois masques de saisie afin de pouvoir traiter toutes nos questions. b) Le logiciel Eclipse :
Nous allons montrer un peu de code sur le logiciel Eclipse, nous y ferons une brève incursion car notre mission s'arrête là. Dans la modélisation, Il faut savoir que le logiciel EA (Entreprise Architecte) seul, ne suffit pas, il nécessite des lignes de code tapées sous le logiciel Eclipse pour faire fonctionner l'agent dialoguant. Sous Eclipse le fichier « bdd-RueDuCommerce.nabu » définit la réponse Machine. Le type de catégorie à activer, la réponse de l'agent et le Push d'url. Sous Eclipse dans le fichier « nlu-ressources.nabu » on envisage toutes les formulations possibles des questions par l'internaute. - La fonction «id : behavior» identifie la question formulée dans Entreprise Architecte. - La fonction « alt » définit l'ensemble des mots qui peuvent être formulés par l'internaute pour poser une question, avec cette option les mots sont distributifs entre eux. La fonction « optional » optionnelle en français définit les mots qui peuvent apparaître de temps à autre. 50 Le fichier « demo-rueducommerce.nabu » permet de charger les deux fichiers cidessous : Sous « E-A », voici le pattern « Behavior » qui fait appel à la partie de code générée manuellement dans Eclipse (feuille précédente) Le fichier « Include.nabu »: sert de jonction avec la base de données afin de mémoriser l'information utilisateur.
|
|