HAL Id: tel-01062263
https://tel.archives-ouvertes.fr/tel-01062263
Submitted on 9 Sep 2014
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
TowardsWeb User-Centric Development
Emilian Pascalau
To cite this version:
Emilian Pascalau. TowardsWeb User-Centric Development. Data Structures and Algorithms [cs.DS]. Conservatoire national des arts et metiers - CNAM, 2014. English. �NNT : 2014CNAM0916�. �tel-01062263�
CONSERVATOIRE NATIONAL DES
ARTS ET MÉTIERS
ÉCOLE DOCTORALE INFORMATIQUE, TÉLÉCOMMUNICATION ET ÉLECTRONIQUE (EDITE - PARIS)
ÉQUIPES VERTIGO - LABORATOIRE CEDRIC
THÈSE DE DOCTORAT
présentée par:
Emilian PASCALAU
soutenue le:7 avril 2014
pour obtenir le grade de: Docteur du Conservatoire National des Arts et Métiers Discipline / Spécialité: Informatique
Vers un développement Web orienté utilisateur
Towards Web User-Centric Development
THÈSEDIRIGÉE PAR
M. RIGAUXPhilippe PR, CNAM
RAPPORTEURS
M. GROSS-AMBLARD David PR, Univ. Rennes 1
Mme. GRIGORI Daniela PR, Univ. Paris-Dauphine
EXAMINATEURS
Mme. BENBERNOU Salima PR, Paris Descartes
M. TRAVERS Nicolas MdC, CNAM
Aknowledgements
I feel obliged to first thank God for the health and strength He gave me through out the years of study. Second I would like to thank my supervisor Prof. Philippe Rigaux, for all his support both academic and moral, without whom I would have never finished my thesis.
Also I would like to thank Dr. Adrian Giurca for our discussions and arguments on the topic. A special thank to my dad for his moral support and to all my friends whom I am not going to name here, but whom in one way or another helped me to get here.
Contents
Résumé iii
Abstract v
Résumé étendu vii
1 Introduction 1
1.1 Objective of this thesis . . . 2
1.2 Our approach . . . 3
1.3 The GPS device metaphor . . . 4
1.4 Contributions . . . 5
2 Related Work on Mashups 9 2.1 Mashups and Web Services / SOA . . . 10
2.2 Semantic Web and Web of Data . . . 12
2.3 Mashups and Software as a Service . . . 12
2.4 Mashups and Portals . . . 14
2.5 Mashups - Conceptual approaches . . . 17
2.5.1 Mashups as a Collection of Widgets . . . 17
2.5.2 Pipes Based Mashups . . . 22
2.5.3 Hybrid . . . 24
2.5.4 Domain Specific Languages for Mashups . . . 29
2.6 Discussion . . . 30
3 A User-centric approach. Conceptual Model 35 3.1 Our proposal - A User-centric approach . . . 36
3.1.1 End-user / user-centric . . . 36
3.1.2 Two layer system . . . 36
3.1.3 Plan . . . 37
3.1.4 Intelligent system and human user and system interacting with each other . . 39
3.1.5 The approach . . . 40 3.2 Conceptual Model . . . 40 3.2.1 Concept . . . 41 3.2.2 Context . . . 43 3.2.3 Behavior . . . 44 3.2.4 Mashup . . . 46 i
CONTENTS ii
4 Architecture 51
4.1 Our Approach vs. GPS metaphor . . . 51
4.2 TomTom . . . 53
4.2.1 Digital maps - The plan . . . 53
4.2.2 How the GPS System Works . . . 54
4.2.3 Outcomes . . . 54
4.3 The Architecture . . . 54
4.4 Discussion . . . 59
4.4.1 Web pages as Web services . . . 59
4.4.2 Mashups styles . . . 60
4.4.3 DOA and SOA influences . . . 61
5 Execution 63 5.1 DOM and DOM events . . . 63
5.2 The Rule Engine . . . 63
5.3 Rules . . . 66 5.3.1 Event . . . 68 5.3.2 Conditional elements . . . 69 5.3.3 Actions . . . 71 6 Implementation 73 6.1 The prototype . . . 73 6.2 Use Cases . . . 76
6.2.1 Conference Calendar - The Recurrent Use Case . . . 76
6.2.2 Security - Web Policies . . . 80
6.2.3 Personalization . . . 80 6.2.4 Web Analytics . . . 82 6.3 Requirements . . . 82 7 Conclusions 85 7.1 Future Work . . . 86 7.1.1 Visual Modeling . . . 86 7.1.2 Mobile Platforms . . . 87
7.1.3 New Reasoning Techniques . . . 87
Résumé
World Wide Web (WWW) est devenu le plus grand dépôt d’informations que l’homme ait jamais assemblé et il est en croissance continue. WWW s’est transformé en un environnement génératif qui favorise l’innovation par le développement des technologies et par un changement dans la perception des gens sur le Web et comment l’utilisent. Le nouveau WWW ou l’Internet de l’Avenir est celui d’un Internet des Services et un Internet des Objets.
Naturellement, une série des questions se posent à partir de ce contexte : comment filtrez-vous les choses pour créer plus de valeur que vous obtenez actuellement ? Comment pouvez-vous regrouper les choses d’une manière intelligente et facile au lieu de la faire dans votre tête? Le monde ne peut pas être décrit sans ambiguïté, alors comment pouvez-vous permettre aux utilisateurs de traiter avec le monde à leur manière, en fonction de leur compréhension? Levine dans son livre "Cluetrain manifesto" a argumenté que les marchés sont conversations, alors comment peut-on impliquer les utilisateurs dans la conversation ? Comment les utilisateurs peuvent être autorisés à la consommation facile des services, de l’information, des choses qu’ils trouvent autour?
Cependant, la conception et le déploiement d’un tel logiciel capable d’interaction directe et l’autonomisation de l’utilisateur final reste toujours un problème. On a, d’une part, les utilisateurs qui ont des idées, mais qui n’ont pas l’environnement technique et les capacités en programmation pour faire eux-mêmes le développement. D’autre part, on a un grand volume des données, ressources et services qui qui pourraient être regroupées à la fois en termes de données, mais le plus important, en termes de comportement d’innover et de créer nouveaux objets.
Notre objectif dans cette thèse est de combler ce manque d’outils qui sont capables d’une inter-action directe et l’autonomisation des utilisateurs finaux, de manière unifiée. Ainsi, notre principale contribution dans cette thèse est le développement d’une approche holistique pour les systèmes basés sur le Web qui sont centrés sur l’utilisateur et qui intègrent des données, les services et le comportement disponible sur le Web 2.0.
Mots clés :
développement web orienté utilisateur, mashups, services web, web 2.0, contexte, comportement
Abstract
World Wide Web (WWW) has become the greatest repository of information that man has ever assembled and it is continuously growing. WWW transformed itself into a generative environment that fosters innovation through the advance of technologies and a shift in people’s perception of the Web and how they use it. The new WWW or Future Internet is that of an Internet of Services and Internet of Things.
Naturally, a series of questions arise from this context: how do you filter things to create more value than you currently get? how do you aggregate things in an intelligent and easy way instead of doing it in your head? The world cannot be described unambiguously, so how can you allow users to deal with the world in their own way, based on their understanding? Levine in his book "Cluetrain manifesto" was arguing that markets are conversations so how can users be involved in the conversation? how can users be empowered with easy consumption of the services, information, things that they found around?
However design and deployment of such software capable of direct interaction and empowerment of the end-user is still an issue. We have on one side users that have ideas, but do not have technical background and lack programming skills to do the development by themselves. On the other side, we have large amounts of data, resources and services that could be aggregated both in terms of data, but most important in terms of behavior to innovate and create new things.
Our goal in this thesis is to address this lack of tools that are capable of direct interaction and empowerment of end-users, in a unified manner. Thus our main contribution in this thesis is the development of a holistic approach for web based systems that are user-centric and that integrate data, services and behavior available on the Web 2.0.
Keywords :
web oriented end-user development, mashups, web services, web 2.0, context, behavior
Résumé étendu
World Wide Web (WWW) est devenu le plus grand dépôt d’informations que l’homme ait jamais assemblé et il est en croissance continue. WWW s’est transformé en un environnement génératif qui favorise l’innovation par le développement des technologies et par un changement dans la perception des gens sur le Web et comment l’utilisent [Zittrain, 2008]. Il "a passé des pages Internet basées sur la transaction aux celles basées sur l’interaction" [Ogrinz, 2009]. WWW a radicalement changé, aussi la façon dont les connaissances sont partagées, en abaissant la barrière pour la publication et l’accès aux documents [Bizer et al., 2010]. En outre, par la prolifération de Web APIs, Web est devenu une plate-forme hautement programmable [Aghaee et al., 2013]. Le nouveau WWW ou l’Internet de l’Avenirest celui d’un Internet des Services et un Internet des Objets.
Selon [O’Reilly, 2007], "Web 2.0 est la révolution des affaires dans l’industrie informatique causée par le passage à l’Internet comme une plate-forme, et une tentative de comprendre les règles de succès sur cette nouvelle plate-forme". Les technologies Web 2.0 sont interactives et obligent les utilisateurs à générer de nouvelles informations et contenus ou à modifier le travail des autres participants [Chul et al., 2009]. Chul et al. continue à déclarer en [Chul et al., 2009] que "la solution correcte vient des participants corrects".
Naturellement, une série des questions se posent à partir de ce contexte : comment filtrez-vous les objets pour créer plus de valeur que vous obtenez actuellement ? Comment pouvez-vous regrouper les objets d’une manière intelligente et facile au lieu de la faire dans votre tête? Le monde ne peut pas être décrit sans ambiguïté, alors comment pouvez-vous permettre aux utilisateurs de traiter avec le monde à leur manière, en fonction de leur compréhension? Levine dans son livre "Cluetrain manifesto" [Levine, 2009] a argumenté que les marchés sont conversations, alors comment peut-on impliquer les utilisateurs dans la conversation ? Comment peut-on autorise les utilisateurs à la consommation facile des services, informations, objets qu’ils trouvent autour d’eux ?
Cependant, la conception et le déploiement d’un tel logiciel capable d’interaction directe et l’autonomisation de l’utilisateur final reste toujours un problème. On a, d’une part, les utilisateurs qui ont des idées, mais qui n’ont pas l’environnement technique et les capacités en programmation pour faire eux-mêmes le développement. D’autre part, on a un grand volume des données, ressources et servicesqui qui pourraient être regroupées à la fois en termes de données, mais le plus important, en termes de comportement d’innover et de créer nouveaux objets.
Objective et contributions
Notre objectif dans cette thèse est de combler ce manque d’outils qui sont capables d’une interaction directe et l’autonomisation des utilisateurs finaux, d’une façon unifiée. Nous sommes préoccupés en particulier des outils fondés sur le Web. Nous affirmons que pour ces systèmes web centrés sur l’utilisateur, utilisateurs, services (dans la forme générale définie en [C. Lovelock, 1996]), sémantique
viii
et contexte sont components clés.
Les mushups sont l’un des paradigmes du Web 2.0. Le terme mashup a été emprunté à la musique et représente une chanson ou une composition créée par le mélange de deux ou plusieurs chansons1. Dans le cas de web un mashup (voire par exemple [Altinel et al., 2007]) a été défini principalement à partir d’une perspective technologique comme une application hybride qui emploi et combine de données, présentation ou fonctionnalité de deux ou plusieurs sources pour créer de nouveaux services, régulièrement par l’intermédiaire de Web APIs2.
Le calendrier des conférences est qu’un exemple – parmi tant d’autres – qui exige un mélange d’idées (utilisateurs, services, données, comportement, contexte) discutés ici pour le rendre possible. Nous allons utiliser cet exemple comme un exemple récurrent, tout au long de cette thèse pour expliquer notre démarche.
Un tel calendrier est spécifique à l’utilisateur, puisque par exemple, certains utilisateurs pourraient être intéressés par web conférences liées, d’autres dans le web sémantique, d’autres règles ou de processus d’affaires des conférences. L’information contextuelle est mashé pour satisfaire l’objectif de certains utilisateurs, donc des informations spécifiques sur les conférences sont stockées dans un contexte de calendrier. Au moins deux services sont requis: celui qui traite avec les conférences et celui qui offre un calendrier. Du point de vue technologique ces services peuvent ne pas être compatibles les uns avec les autres.
Pour les scientifiques dans le domaine de l’informatique, la liste de diffusion DbWorld est l’endroit bien connu où ils peuvent rechercher une conférence en informatique. Une série d’informations sont fournies ici, mais le plus important c’est l’objet, le délai et la page Web de l’événement publié. D’un point de vue technique, DBWorld ne fournit pas d’API pour permettre l’accès programmatique et l’interrogation du service. En conséquence, par rapport à des approches de mashups actuelles, ce service est inutile.
D’autre part, le Calendrier Google est l’une des applications Google Apps les plus connus. L’information d’intérêt pour le calendrier est le titre de l’événement, la date et la description d’un événement. Ces informations se trouvent dans un Calendrier Google. Contrairement aux services DbWorld, Google fournit pour ce service, en plus de la représentation de la page Web, une API pour accéder au contenu. Cette situation est tout simplement un exemple qui soutient la nécessité d’être en mesure de traiter de façon non-uniforme l’accès aux services.
La voie habituelle pour atteindre cet objectif d’avoir des conférences stockées dans le Calendrier Google par leur date limite nécessite des interactions manuelles: (1) l’utilisateur doit maintenir deux onglets ouverts dans le navigateur; (2) même s’il peut y avoir plusieurs entrées qui sont conformes à un terme de recherche, l’utilisateur doit traiter les événements un par un parce que DBWorld ne fournit pas une construction dans la fonctionnalité de recherche; (3) l’utilisateur doit se déplacer entre les onglets ouverts à plusieurs reprises, afin de stocker un seul événement dans le calendrier, car un seul élément d’information peut être copié et collé à la fois (par exemple, le titre de l’événement).
Contribution
Le contenu de cette thèse réside à la confluence entre les thèmes suivants: Génie Logiciel, Architectures orientées vers les services, Sensibilité au contexte, Sémantique Web et Raisonnement, Management du procès des affaires et Systèmes d’information.
Le travail présenté tout au long de cette thèse est présenté principalement du point de vue du génie logiciel (Software Engineering). On concentre un peu sur la construction des théories et sur les rendre
1
http://en.wikipedia.org/wiki/Mashup_(music), retrieved 9 December 2013
CHAPTER 0. RÉSUMÉ ÉTENDU ix
explicites [Sjøberg et al., 2008, Easterbrook et al., 2008] au sein du génie logiciel parce que nous employons des connaissances de plusieurs sujets, comme nous l’avons indiqué précédemment, nous trouvons important de préciser que la position philosophique [Easterbrook et al., 2008], nous adoptons le pragmatismepour notre méthode de recherche.
Le pragmatisme reconnaît que toute connaissance est approximative et incomplète, et que sa valeur dépend des méthodes par lesquelles elle a été obtenue [Easterbrook et al., 2008, Menand, 1997].
Pour les pragmatistes, la vérité est ce qui fonctionne à l’époque, entraînant un degré de relativisme. C’est-à-dire, ce qui est utile pour une personne peut ne pas être utile pour une autre, par conséquent la vérité est relative pour l’observateur [Easterbrook et al., 2008]. Pragmatisme adopte une approche d’ingénierie pour rechercher la valeur des connaissances pratiques sur la connaissance abstraite. On utilise des méthodes de recherche mixtes pour faire la lumière sur la question à l’étude.
Notre contribution principale est le développement d’une approche holistique pour les systèmes web qui sont centrés sur l’utilisateur et qui intègrent les données, les services et le comportement disponible sur le Web 2.0.
Nous croyons que l’approche que nous avons développée nous amène un pas de plus près pour permettre aux utilisateurs finaux de programmer leurs propres applications. Par ailleurs l’approche que nous avons développée est de compléter les techniques existantes.
En détails, nos contributions sont présentées en plusieurs étapes:
• Étape 1ère: Nous commençons par aborder l’aspect conceptuel du problème. Nous revisitons les technologies web actuelles avec un accent sur les applications mashups à partir d’un point de vue conceptuel et de discuter les concepts que nous allons utiliser dans notre approche.
• Étape 2ème: Nous proposons une architecture qui hérite des caractéristiques de l’appareil de la métaphore TomTom, et considère l’utilisateur comme étant un composant du système. Les principes de la SOA, SaaS et Web sont mélangés dans une solution hybride.
• Étape 3ème: Nous développons la sémantique opérationnelle du système.
• Étape 4ème: Nous discutons l’implémentation de la mise en œuvre de tels systèmes, nous fournissons un ensemble de cas d’utilisation, et nous décrivons un prototype roulant qui constitue une preuve de concept de notre approche.
Chaque étape est présentée dans un chapitre dédié.
Chapitre 2 est consacré à l’examen des travaux connexes. Des différentes approches Mashups sont discutées avec les tendances influentes et les technologies qui forment les bases pour le développement des mashups. Nous discutons aussi la raison pour laquelle nous considérons mashups que des travaux connexes pertinents et nous exposons notre opinion sur la raison pour laquelle certaines des techniques de mashups ont été abandonnées ou ont été intégrées dans les grands projets. Nous concluons le chapitre avec une liste des exigences auxquelles l’approche et le système que nous allons présenter dans les prochains chapitres doivent se conformer.
Chapitre 3. Dans ce chapitre nous présentons notre approche conceptuelle. Cette approche est fortement orientée vers l’utilisateur final. L’approche prévoit un système composite qui comprend un utilisateur humain et un système intelligent. Nous discutons des aspects conceptuels qui animent notre approche: l’utilisateur final / centrée sur l’utilisateur; plan; système à deux couches; système intelligent;
x
humaine - l’interaction du système. Deuxième partie du chapitre décrit le modèle conceptuel associé à notre approche.
Chapitre 4. Nous proposons une architecture pour les systèmes que nous discutons tout au long de cette thèse. Cette architecture suivie la métaphore TomTom. Elle est influencée par Newell [Newell, 1994] Model du processeur humaine et hérité de l’architecture orientée vers les services et de
l’architecture orientée vers la distribution.
Chapitre 5. Nous proposons un modèle d’exécution basé sur une technique de raisonnement de chainage avant.
Chapitre 6. Ce chapitre affirme une série de lignes directrices de mise en œuvre sur la façon dont ces systèmes devraient être mis en œuvre. Une série de cas d’utilisation sont présentés dans ce chapitre. Ces cases d’utilisation seront employées pour valider notre approche. Nous discutons également de la mesure dans laquelle les exigences que nous avons identifiées dans le chapitre 3 ont été respectées. Un prototype roulant de notre approche sera décrite dans ce chapitre.
Chapitre 7. Les conclusions du travail présenté dans cette thèse sont énumérées dans ce chapitre avec les futures étapes sur façon dont ce travail peut être amélioré.
Chapitre 2 Résumé - Travaux connexes sur Mashups
Dans le deuxième chapitre, nous examinons les travaux existants dans le domaine des services Web, Web 2.0, Web sémantique, les services Web sémantiques, Web des données présentant leurs influences sur le développement d’outils de mashup.
Au meilleur de nos connaissances, nous ne sommes pas au courant de toute autre enquête sur ces dimensions et qui traite de tels nombreux aspects liés au développement de mashups.
Mashups sont l’une des paradigmes Web 2.0 et une zone de l’application End User Development (EUD) prometteuse [Grammel et Storey, 2008]. Nous croyons qu’ils sont le plus étroitement liés du type du case d’utilisation que nous avons énoncé dans le Chapitre ch:introduction.
Plusieurs définitions ont été données pour définir le concept de mashups. Altinel et al. Altinel et al. [Altinel et al., 2007] définit un mashup comme
une application web qui combine le contenu de deux ou plusieurs applications pour créer une nouvelle application. Les applications situationnelles sont des applications web d’entreprise reposant sur la volée pour résoudre un problème commercial spécifique. Elles sont souvent élaborées sans la participation du département informatique et opèrent en dehors de son contrôle. Elles combinent les données provenant d’une variété de sources d’entreprise telles que SAP ou des applications Office, bases de données back-end, et les systèmes de gestion de contenu.
Bien que toutes les définitions fournies soulignent plus ou moins les mêmes caractéristiques, Eric Schmidt de Google définit ces nouvelles applications comme
"applications qu’on l’assemble ” - avec les caractéristiques que les applications sont relativement faibles, les données sont dans le nuage, les applications peuvent fonctionner sur n’importe quel appareil (PC ou mobile), les applications sont très rapides et très personnalisable, et sont réparties de manière virale (réseaux sociaux, e-mail, etc).3
3
CHAPTER 0. RÉSUMÉ ÉTENDU xi
Un aspect que nous soulignons dans la première partie de notre étude est que la plupart des services Web (par exemple SOA, Web sémantique et le Web des données, Software as a Service) les technologies relatives ont influencé d’une certaine manière le développement de mashups. Nous continuons plus tard avec la présentation d’une large palette de mashups approches: mashups comme une collection de widgets, mashups basés sur les tuyaux; des approches de mashups hybrides; domaine des langues spécifiques pour les mashups.
Sur la base des nombreuses réflexions sur les tendances qui ont influencé la création de mashups ainsi que sur la base des orientations de recherche identifiés par le Groupe d’experts FP8 l’UE travaillant sur les services dans l’Internet du futur4, dans les paragraphes qui suivent nous allons faire une série d’affirmations et considérations sur les raisons pour lesquelles nous croyons que les approches actuelles n’ont pas vraiment atteint le résultat souhaité ; nous extrayons un modèle commun minimal pour mashups basé sur les approches de mashups présentées dans le chapitre ; nous énumérons les exigences que nous considérons avec lesquels une approche de mashup doit se conformer. Notre approche, que nous allons élaborer et présenter dans cette thèse sera conforme aux besoins identifiés.
Bien que les mashups ont été d’abord pensés et développés qu’à partir d’un point de vue technique, principalement par le biais des hacks, nous croyons que le côté conceptuel du problème doit être pris en compte.
Le développement de mashup représente une zone d’application du End User Development (EDU) prometteuse comme le fait valoir dans [Grammel et Storey, 2008]. En utilisant les services qui peuvent être accessibles par le Web comme plate-forme sous-jacente, l’effort de développement est passé de la programmation traditionnelle. C’est pourquoi les difficultés rencontrées par les designers des outils mashup comprennent la nécessité de définir un moyen de haut niveau pour la description et la combinaison du calcul, de la logique d’intégration et des abstractions pour représenter les widgets Web, les services Web, les sources de données sur le Web [Aghaee et al., 2012]. Néanmoins, ces objectifs n’ont pas encore été atteints.
Un grand nombre d’outils de mashups ont été développés à la fois dans les universités et dans l’industrie, mais seulement quelques-uns ont réussi. Un grand nombre de ces approches, même si ont été développés par les grandes entreprises comme Microsoft ou Google ont été abandonnées, à savoir Microsoft Popfly, Google Mashup Editor. D’autres, comme JackBe Presto ou Serena Mashup Composer sont encore en usage. Nous croyons qu’il y a un grand intérêt pour ces outils tant dans le milieu universitaire que dans l’industrie et de nouveaux cadres sont en cours de développement, c’est à dire [Aghaee et al., 2013]. Dans le même temps, nous pensons que les approches actuelles n’ont pas vraiment atteint le résultat souhaité car elles étaient soit trop technique ou trop scientifique, et qu’elles n’avaient pas une bonne intégration entre la perspective technique et la perspective conceptuelle. De cette manière, ces approches ont perdu sur le chemin la cible fondamentale - l’utilisateur final. Nous croyons que cet état vient du fait qu’à l’heure actuelle le processus de développement de logiciels en génie logiciel est principalement axée autour de la structure du logiciel en cours de construction et des interactions entre ses composants. Alors qu’en réalité l’accent devrait être mis sur les utilisateurs finaux.
Les clients de mashups Albeit qu’on fait valoir dans [Bioernstad et Pautasso, 2007] sont mashup réels, la quasi-totalité des approches que nous avons discuté dans ce chapitre sont les mashups côté du serveur. Nous croyons que les approches centrées sur l’utilisateur pour les mashups devraient être des mashups basés sur le client. Les utilisateurs finaux ne devraient pas être tenus d’installer, de configurer et de maintenir des serveurs. Les utilisateurs finaux doivent toutefois recevoir les outils qui sont en
4http://cordis.europa.eu/fp7/ict/ssai/docs/fp8-preparations/questions.pdf, extrait le 13 janvier 2014
http://cordis.europa.eu/fp7/ict/ssai/docs/fp8-preparations/researchchallenges.pdf, extrait le 13 janvier 2014
xii
général suffisantes pour répondre d’une manière unifiée et holistique à la plupart des technologies énumérés ici. Ces outils doivent cacher autant que possible le côté de l’ingénierie et les technologies. En outre, ces outils devraient être les mêmes, peu importe le type d’appareil qui est utilisé. Nous affirmons que ces outils peuvent être atteints par l’avance de HTML5 et JavaScript. Nous pensons qu’une solution basée sur un navigateur peut se conformer à tous ces aspects. D’autres chercheurs sont d’accord avec nous sur ce sujet. On pourrait voir par exemple [Aghaee et Pautasso, 2010].
La liste des exigences que nous croyons un système de mashup orientée vers l’utilisateur final doit respecter :
E1 un tel système doit permettre l’évolution, le partage et la distribution ; les utilisateurs finaux doivent être autorisés par saisie directe de mettre à jour / adapter l’application;
E2 un tel système ne devrait pas être un domaine spécifique, et devrait permettre un large éventail de cas d’utilisation;
E3 dans un tel système l’utilisateur final devrait être le coordonnateur de la façon dont le système fonctionne, d’où le système doit permettre un nouveau modèle de programmation pour les systèmes composites (homme + services)5;
E4 un tel système devrait soutenir les développeurs qualifiés ainsi que les utilisateurs novices;
E5 un tel système devrait se concentré sur l’utilisateur final et pas sur le système lui-même. Le système doit être caché à l’utilisateur final autant que possible en fournissant le bon niveau de représentation tels que la représentation de problème pourrait être traduit automatiquement dans les concepts de base de la langue de programmation sous-jacent dans lequel le système global est mis en œuvre;
E6 un tel système devrait permettre sur le développement de la demande en utilisant le web comme une plate-forme Web comme un environnement d’exécution de l’application: s’appuyer sur des idées, des sites, des applications existantes6;
E7 un tel système doit être conforme aux principes de la SOA de: couplage de poux, réutilisation, possibilité de découvrir, compossibilité;
E8 un tel système doit permettre l’exécution décentralisée et délocalisée de logiciels / composants7;
E9 ces systèmes devraient permettre un moment de la construction simultanée, le développement des temps d’exécution et l’expérience8.
Ayant cette discussion comme point de départ, nous présenterons dans le chapitre 3 de notre approche ainsi que le modèle conceptuel que nous proposons d’aborder les questions soulignées dans le chapitre 2.
5
http://cordis.europa.eu/fp7/ict/ssai/docs/fp8-preparations/questions.pdf, extrait le 13 janvier 2014
6
http://cordis.europa.eu/fp7/ict/ssai/docs/fp8-preparations/questions.pdf, extrait le 13 janvier 2014
7
http://cordis.europa.eu/fp7/ict/ssai/docs/fp8-preparations/researchchallenges.pdf, extrait le 13 janvier 2014
8
CHAPTER 0. RÉSUMÉ ÉTENDU xiii
Chapitre 3 Résumé – Une approche centrée sur l’utilisateur. Model
con-ceptuel
Nous avons souligné dans le chapitre 2 une série de caractéristiques et des exigences avec lesquels nous croyons que les mashups centrés dur l’utilisateur doivent se conformer.
Ainsi, tels systèmes devraient être centrés sur l’utilisateur. Tels systèmes devraient permettre un nouveau modèle de programmation pour les systèmes composites (hommes + services) E3.. Nous soutenons que ces systèmes soient des systèmes intelligents étant capable d’interagir avec l’utilisateur final selon un plan convenu à l’avance, en soutenant l’évolution, le partage et la distribution E1. Par conséquent, ces systèmes sont deux systèmes de couches: une couche de haut niveau, qui traite le problème à un niveau conceptuel et sémantique (l’accord sur le plan) et une couche de bas niveau qui traite des internes du système et des technologies de bas niveau, par exemple, accès direct aux services, etc. La couche de bas niveau doit être cachée, autant que possible de l’utilisateur final E5.
Les aspects (également représentées sur la figure 1) qui conduisent au développement de notre approche sont: orienté vers l’utilisateur final ou centrée sur l’utilisateur ; les humains et le système d’interagir avec l’autre; régime; système à deux couches; système intelligent. Ces aspects ont déjà été discutés dans la littérature de recherche, mais presque toujours d’une manière de déconnexion avec presque pas d’interaction entre eux. En outre une terminologie différente, selon les orientations de la recherche où il a été étudié, a été utilisée pour identifier réellement le même concept.
Our Approach
End-user / user-centric Two layer system
Intelligent system
Plan Human user and intelligent system interaction
Figure 1: Aspects that drive our approach
Ce chapitre décrit l’approche proposée par nous et le modèle conceptuel que nous avons crée dans la relation avec notre approche.
L’approche
Le développement de l’utilisateur final a été défini dans [Lieberman et al., 2006] comme une
une série des méthodes, techniques et outils permettant aux utilisateurs des systèmes logiciel qui agissent comme développeurs de logiciel non-professionnel, à un certain point de créer, modifier ou étendre un artefact logiciel.
La recherche en génie logiciel de l’utilisateur final est interdisciplinaire [Lieberman et al., 2006] impliquant les idées : Informatique, génie logiciel, l’interaction homme-ordinateur, de l’éducation, de la psychologie et d’autres disciplines.
Les utilisateurs finaux que nous voulons soutenir, sont la plupart, pas des développeurs profes-sionnels, qui manquent de compétences techniques, et qui n’ont pas les connaissances nécessaires pour écrire des programmes logiciels, selon les spécifications techniques (cahier des charges pour les
xiv
services Web, les API, REST etc.). Les utilisateurs finaux ont une variété des objectifs. Ces objectifs sont atteints par la création de nouvelles applications, par brassage des applications existantes, ou des artefacts logiciels, par la modification ou l’adaptation des applications existantes.
Maintenant, afin de permettre aux utilisateurs finaux, qui ne sont pas des programmeurs profes-sionnels à programmer, adapter les applications existantes ou des artefacts logiciels en fonction de leurs besoins la couche technique a besoin d’être caché, autant que possible, sinon ils ne seront pas en mesure de le faire.
Pour réaliser cette séparation des préoccupations et ainsi cacher la couche technique, nous soutenons qu’il est nécessaire un système à deux couches. La couche de haut niveau devrait fournir les moyens pour permettre à deux utilisateurs de l’homme et le système de comprendre l’autre en utilisant un ensemble commun de concepts et suite à une avance d’accord sur le plan. D’autre part, la couche de bas niveau doit être caché à l’utilisateur final et doit être accessible directement par le système en fonction de ce qui a été convenu dans le plan. Un développeur professionnel devrait également être autorisé à accéder à cette couche.
Le génie logiciel est le domaine de l’étude qui se préoccupe de tous les aspects liés à la conception et le développement de systèmes logiciels. Deux de ces aspects: ingénierie des exigences et la conception du système sont d’intérêt pour notre approche, parce que le comportement interne du système cible alors que les besoins sont externes, concernant le monde.
La phase de la collecte des besoins précède la conception du système. Malheureusement, dans la plupart des cas, le produit final n’est pas conforme aux attentes de l’utilisateur final pour diverses raisons: à savoir une mauvaise communication, une compréhension différente des concepts et des situations, etc. [Tognazzini, 1992, Nardi, 1993]. Un utilisateur final perçoit et comprend un système logiciel par l’intermédiaire de l’interface d’utilisateur (UI). Basé sur l’interface d’utilisateur, qui est devrait être une représentation exacte et complète du système, l’utilisateur final construit sa propre compréhension de l’environnement constitué de concepts avec lesquels il travaille, et le comportement associé [Clark et Sasse, 1997]. Impuissante dans de nombreuses situations de la compréhension de l’utilisateur final est très différent de la compréhension et le message, les développeurs ont essayé effectivement de transmettre [Tognazzini, 1992].
Une exigence dans l’ingénierie des exigences (Requirements Engineering (RE)), comme indiqué dans [Pohl, 2010],
définit tant les besoins que les objectifs des utilisateurs, et les conditions et propriétés du système à développer, ce résultat, par exemple, de besoins organisationnels, des lois ou des normes.
Dans l’ingénierie des exigences un objectif est l’intention de parties concernant les objectifs, les propriétés ou l’utilisation du système [Pohl, 2010]. Les exigences définissent ce qui doit être développé tandis que la conception de système définit la façon dont le système doit être développé [Pohl, 2010]. En conséquence, nous débattons que l’ingénierie des exigences signifie la couche de haut niveau tandis que la conception du système correspond à la couche de bas niveau. Et par conséquent, nous croyons que les deux l’ingénierie des exigences et la conception du système doivent être unifiés lorsqu’il s’agit de systèmes intelligents appropriés centrés sur l’utilisateur (voir figure 2).
Les approches de l’ingénierie des exigences proposent aussi l’utilisation de scénarios, qui représen-tent des exemples concrets, positifs ou négatifs de satisfaction ou l’échec de satisfaire un objectif ou un ensemble d’objectifs [Pohl, 2010]. Tels scénarios pour notre approche sont les plans que les utilisateurs finaux créent. Configuration logicielle sont généralement exprimés en langage naturel. Cependant le langage naturel ne peut pas être une option ici. Nous avons besoin d’un ensemble structuré et bien défini de concepts pour exprimer les plans de l’utilisateur final, telles que un système intelligent peut
CHAPTER 0. RÉSUMÉ ÉTENDU xv Software development what Requirements engineering how System design plan (visible)
What needs to be done to fulfill goal
(hidden)
How should the system be implemented
Figure 2: Software development aspects
comprendre, raisonner et utiliser ce plan, dans son interaction avec l’environnement et l’utilisateur final.
Par conséquent, un plan d’utilisateur final comprend un ensemble de concepts, avec laquelle l’utilisateur final fonctionne afin de satisfaire un objectif, leur relation les uns avec les autres, le cadre, et un moyen pour exprimer le comportement aux formes de processus et des règles. Ainsi, pour notre approche l’utilisateur dispose d’un plan de ce qui doit être fait pour atteindre un objectif. Les besoins à faireici signifie l’interaction (comportement) que l’utilisateur doit exposer avec l’application (applications) afin de remplir l’objectif. En outre l’utilisateur attend une réponse particulière du système en réponse à des actions il / elle, l’utilisateur, effectue. Le comportement de l’utilisateur est imposé (influencé) par le contexte (environnement).
Pour l’approche que nous envisageons et conceptions dans cette thèse, l’utilisateur crée un plan qui est partagé (donné) au système. Ce plan contient une description du contexte(s) et le comportement que tant l’utilisateur humain et le système doivent effectuer en relation avec le contexte (s) comme nous avons introduit dans [Pascalau, 2011a]. Le plan explique comment le système doit réagir en réponse aux actions que l’utilisateur humain effectue, ou comment le système doit réagir en réponse aux changements qui apparaissent dans l’environnement (contexte(s)). De cette façon, tant l’utilisateur humain que le système suivront et partagent la même compréhension, le même plan.
Les deux derniers aspects que nous avons identifiés concernant notre approche sont les suivants: système intelligentcapable d’interagir avec l’utilisateur humain selon le plan convenu.
Nous affirmons que notre système peut être assimilé à la notion d’un agent. Un agent hybride: une combinaison entre un agent réactif, un agent déductive et également agent proactif.
Nous relions ainsi les aspects que nous venons de discuter et nous reprenons notre approche à la figure 3. L’approche que nous avons introduite dans cette section propose un nouveau modèle de programmation grâce à un système composite où l’utilisateur humain et le système se trouvent en interaction les uns avec les autres. L’interaction se fait via l’environnement et selon un plan prédéfini. Ce plan est créé par l’utilisateur humain, d’où l’homme est le coordinateur de la façon dont le système fonctionne. Tant le système intelligent que l’utilisateur humain suivent le même plan. Ce plan sert à atteindre un objectif particulier et elle a été créée prenant en compte le contexte(s). Interaction est perçue par les changements qui apparaissent dans l’environnement.
Le modèle conceptuel
Nous avons annoncé précédemment que la manière appropriée de définir notre modèle conceptuel est au moyen d’ontologies [Guarino, 1998]. Les instances de ce modèle représenteront le plan que l’utilisateur va fournir au système.
xvi
user System according
to our approach Plan (same understanding) uses uses Context(s) = environment created by perceives perceives imposed (influenced) interact via according to
Figure 3: Our approach
Comme le UML est considéré le standard modelant le langage [Guizzardi, 2005], nous l’employons aussi pour formaliser notre cadre conceptuel.
Concept
Bien que de nombreuses approches ontologiques (voir, par exemple, OWL [Group, 2009]) utilisent comme l’entité de niveau supérieur, la notion d’objet pour notre cadre conceptuel l’unité la plus générale de la connaissance est la notion de concept. En outre, la spécification de l’OMG pour la Sémantique du Vocabulaire des Affaires et les Règles (SBVR) [OMG, 2008] utilise comme entité de top la notion de concept notion.
Un concept a un nom et un ensemble de propriétés. Il s’agit d’une sous-classe uml::Class entité. Il peut être identifié soit par son nom ou par l’ensemble (ou un sous-ensemble) des propriétés qui le définissent. En génie logiciel lorsqu’il s’agit de langages typés, les entités sont reconnues par leurs types (nom de la classe). Le sens inverse est basé sur un ensemble de caractéristiques.
Dans notre approche les deux points de vue sont pris en compte.
Un concept représente une unité de connaissance créée par une combinaison unique de caractéris-tiques. Ainsi, comme le montre la figure 4, chaque élément du cadre est un concept. De cette façon, le processus de raisonnement peut entraîner aucune des concepts définis de manière unifiée.
Rappelons le cas d’utilisation du calendrier des conférences que nous avons introduit dans le chapitre 1. L’objectif est de stocker automatiquement les événements qui sont annoncés dans la liste de diffusion DbWorld dans un calendrier Google. Sans une approche similaire à celle décrite dans cette thèse, pour atteindre cet objectif de stocker automatiquement les événements dans un calendrier Google on a besoin de deux onglets ouverts dans le navigateur, nécessaire pour aller et retour entre ces deux onglets et copier et coller chaque élément d’information manuellement pour chaque événement. La figure Figure 5 représente le service de calendrier Google - l’événement facette de sauvegarde.
Le service de calendrier Google est un exemple de concept de Service. Depuis un concept possède des caractéristiques, la caractéristique d’intérêt pour nous est l’URL du service:
CHAPTER 0. RÉSUMÉ ÉTENDU xvii Concept Action Event Message Rule Process Mashup Context Entity Service Human uml::Class uml::Property 1 * Object Figure 4: Concepts
Figure 5: Google calendar service - save event facet
https://www.google.com/calendar/. Un autre concept de l’intérêt pour notre cas d’utilisation est l’existence du bouton Save. Empiriquement à partir d’un point de vue de l’utilisateur final d’identifier le bouton Sauver comme le bouton de sauvegarde exige que le bouton est un bouton et a le contenu du texte Save. Une représentation réelle, comme un arbre DOM, du bouton d’enregistrement selon le modèle de Google actuelle, à l’intérieur d’un navigateur, est représenté dans l’exemple 0.0.1. Ainsi, dans le but d’identifier le bouton Sauver, la représentation de l’arbre DOM du service de calendrier Google doit contenir un concept qui présente les caractéristiques suivantes: type de valeur div, classavec la valeur goog-imageless-button-content, et textContent avec la valeur
xviii
Save.
Example 0.0.1 (Google Calendar Save Button DOM representation). <div class="goog-imageless-button-content">
Save </div>
D’une façon similaire on peut identifier tous les autres concepts nécessaires pour ce cas d’utilisation.
Contexte
Pour notre cadre conceptuel la notion de contexte adhère à l’appareil mathématique défini dans [Analyti et al., 2007], mais ici le contexte est un ensemble de concepts et pas un objet.
Un concept constitué d’un identificateur de contexte et un ensemble d’identificateurs de concepts. Basé sur le mécanisme d’identification des concepts le contexte est identifié respectivement en identifiant de manière récursive tous les concepts constitutifs.
Example 0.0.2. Un contexte dans notre cas d’utilisation Calendrier Google comprendrait, par exemple, le concept se référant au service de calendrier Google et les deux concepts nécessaires pour identifier le bouton Sauver. Ainsi, le système afin d’être en mesure de dire qu’il est en cours d’exécution dans ce contexte particulier on doit trouver les trois concepts qui sont compris dans ce contexte.
Comportement
Traditionnellement le comportement a été défini par des business rules et des business processes [Weske, 2007]. Notre cadre conceptuel est d’accord avec cette approche. En outre, nous pensons que le comportement est fortement lié au contexte(s) [Pascalau, 2011a]..
Le comportement d’une entité représente l’ensemble des événements, des actions et des messages que cette entité produit. Un événement est une occurrence d’un phénomène observable. C’est quelque chose qui "se passe", un événement qui est détectée, soit un click sur un bouton. Un événement a la même signification tant dans le cas d’une règle ainsi que d’un processus. Les événements peuvent être connectés à la fois.
Le comportement est un ensemble de règles et / ou un ensemble de processus, ou une combinaison des deux, liée au contexte(s).
Example 0.0.3 (Exemple de Règle).
Si un événement de clic a été relevé de la touche de recherche réside dans le contexte de services de calendrier et il y a un champ de recherche dans ce même contexte et la valeur du champ de recherche est trouvée dans la colonne de l’objet du contexte de service DbWorld et il y a pour chaque événement une date de départ dans la même ligne que la
colonne de l’objet et un emplacement, puis sauver cette entrée d’événement.
Mashup
En conséquence un mashup est un plan (carte) qui décrit le contexte(s) et le comportement afférent qu’un utilisateur doit faire pour atteindre un but désiré. Une telle mashup est définie à partir d’un point de vue de l’utilisateur.
Un mashup est un ensemble de contextes et comportement.
La figure 6 illustre le cadre général. Ainsi, le concept de Mashup contient une ou plusieurs contextes. En outre, un Mashup peut contenir processus, règles ou une combinaison des deux. Un contexte est essentiellement une collection de concepts. En outre, un contexte pourrait avoir des sous-contextes. Un contexte fait référence à une entité.
CHAPTER 0. RÉSUMÉ ÉTENDU xix Context Mashup Concept 1 1..* 1 1..* Rule 1 * Process Entity 11 * * * * 1 * * *
Figure 6: Mashup Concept
Chapitre 4 Résumé – Architecture
L’architecture que nous proposons dans ce chapitre suit l’approche que nous venons d’introduire auparavant. Au meilleur de notre connaissance, il n’existe pas de système liés au contexte web: (1) qui suit une approche à deux couches pour la conception du système, (2) qui utilise une représentation unique étant compris tant par l’utilisateur que par le système de la même voie; (3) qui estime et exige à l’utilisateur final de participer activement dans le système afin d’atteindre un objectif désiré.
En dépit de cette lacune dans le contexte Web afférent - dont nous soutenons qu’elle peut être remplie avec une approche similaire à celle introduite dans cette thèse – il y a une approche similaire dans les caractéristiques au sein d’un domaine différent. Le système TomTom9est probablement l’un des plus connu et le plus évolué [TomTom, 2007]] parmi les systèmes global de positionnement (GPS)10. Ainsi TomTom est un exemple de la métaphore du GPS que nous l’avons précisé dans l’introduction de cette thèse. L’architecture que nous proposons hérite des appareils TomTom.
Dans la figure 7, est représentée la métaphore GPS d’un système complet nécessaire pour trouver une personne, par exemple, de Paris à Berlin. Les acteurs impliqués sont l’utilisateur humain (qui est au volant d’une voiture) et le système intelligent qui dans ce cas est le système GPS. Tant l’utilisateur humain que le GPS utilisent un plan (ici une carte) pour atteindre l’objectif souhaité de se rendre à Berlin. La carte contient la description du contexte(s) à savoir les villes, les routes, etc. Le comportement est également spécifié. Une particularité de ce système est que pour définir le comportement, l’utilisateur introduit directement ce comportement en spécifiant la route exacte à suivre et dans ce cas le système GPS vérifie si l’utilisateur humain a dévié du comportement défini. Ou bien, la deuxième possibilité consiste simplement à définir le début et la fin de l’emplacement et le GPS calcule l’itinéraire qui doit être suivi par l’utilisateur humain. L’utilisateur final est également une partie du système, parce que si l’utilisateur ne conduit pas le véhicule, le but recherché ne sera jamais atteinte. Au moment même où le système GPS perçoit l’environnement par la réception des événements par les satellites il est en mesure de calculer en permanence la position actuelle ainsi.
Nous croyons que les similarités entre notre approche et la métaphore du GPS peuvent être facilement observés. La métaphore GPS suive en même temps le système à deux couches que nous
9
http://www.tomtom.com/
10
http://en.wikipedia.org/wiki/GPS
xx
GPS
Entire System required to get from Paris to Berlin User Route Car Satellites sets follows drives follows sets send informs Figure 7: GPS Example
avons identifié pour notre approche. De même, on utilise un plan qui a été défini par l’utilisateur final et puis donné eu système intelligent. Le plan (la carte) dans le cas du GPS comprend aussi une définition du contexte(s) et le comportement qui doit être suivi tant par l’utilisateur humain que par le système intelligent. Le plan est compris de la même façon par toutes les parties concernées. Le comportement est perçu aussi par les changements qui apparaissent au sein de l’environnement (contextes). Tant l’utilisateur humain que le système sont nécessaires, comme components actives du système général, pour attendre l’objectif désiré par l’utilisateur final. Par conséquent, nous soutenons que la métaphore du GPS est un exemple précis de notre approche.
De notre point de vue les aspects les plus importants que nous apprenons de l’appareil TomTom sont: d’abord que, la couche de bas niveau du système (le niveau du système) a été conçue par défaut comme système en temps réel et la seconde qu’au niveau du système, il y a une façon unifiée pour représenter l’information. Nous soutenons que ces deux aspects constituent le sous-sol et sont des exigences fondamentales pour les systèmes conformes à la démarche que nous avons introduit la construction. Etre en temps réel permet la spécification du comportement. La manière unifiée pour la représentation de l’information est l’obligation pour le plan défini par l’utilisateur final et pour la construction d’un système intelligent qui peut être conscient de lui-même et de l’environnement.
L’architecture
L’architecture que nous présentons ici concerne les navigateurs web, en raison de plusieurs raisons. Tout d’abord, selon les derniers commentaires qui ont fini la section précédente, les navigateurs Web sont en effet en temps réel, et ils offrent aussi une façon unifiée pour représenter l’information. En plus
CHAPTER 0. RÉSUMÉ ÉTENDU xxi mashups engine google.com yahoo.com wikipedia.com spiegel.de browser WWW spiegel.de web site mymashup.com mymashup.com mashup user Legend:
Figure 8: The General Architecture
de la représentation unifiée de l’information, les navigateurs Web fournissent également une manière unifiée de programmation et accès. En outre, presque tous les utilisateurs finaux savent comment utiliser un navigateur Web ; un navigateur web existe presque sur tous les dispositifs réels, allant de consoles de jeux, les récepteurs de télévision, les téléphones intelligents, les tablettes, les ordinateurs de bureau. La technologie est la même partout ; toutes les systèmes d’opération ont été construites comme un navigateur web, voir par exemple Google Chrome OS11, Firefox OS12; un grand nombre de kits de développement du logiciel pour la création d’applications mobiles multiplateformes sont construites en utilisant HTML5 + JavaScript. Voir par exemple Sencha Touch 213, PhoneGap14, jQuery Mobile15.
L’architecture générale d’un système respectant l’approche que nous avons introduit (voir la Figure 3) et qui est similaire aussi avec les appareils TomTom sont illustrés dans la Figure 8.
Cette architecture est adaptée pour le web. Comme on peut le voir de l’image, le moteur de mashup fait partie du navigateur, ce qui lui donne un accès privilégié tant au contenu du navigateur lui-même qu’aux pages Web qui peuvent être accessibles via le navigateur.
On peut imaginer tout le système comme un type spécial d’aquarium qui n’a pas de fond. Le navigateur enrichi d’un tel moteur de mashup est enfoncée dans l’eau. Ainsi, l’utilisateur du navigateur et par conséquent l’utilisateur du moteur de mashup ont accès à tous les services auxquels le navigateur et le moteur de mashup ont accès. Tant l’utilisateur du navigateur que le moteur de mashup "regardent"
11 http://www.chromium.org/chromium-os 12 http://www.mozilla.org/en-US/firefox/os/ 13http://www.sencha.com/products/touch/ 14 http://phonegap.com/ 15 http://jquerymobile.com/ Emilian Pascalau, 2014
xxii Envir onm en t Mashups Engine gMail.com wikipedi a.com user browser Rule System DOMActuator Actuator ??? DOMSensor Sensor ???
Figure 9: Mashups Engine
les services comme de l’extérieur d’une boîte. De l’intérieur de la boîte on ne voit pas trop. Mais de l’extérieur de la boîte, on peut voir tout ce qui se trouve à l’intérieur de la boîte ainsi que la boîte elle-même. Ici on applique le même principe.
En principe, les pages web accédées par un navigateur ont quelques couches. Il y a les couches JavaScript et Ajax. Le code JavaScript peut être partagé dans quelques fichiers et chargé de plusieurs locations. La même règle s’applique pour les objets Ajax. Ensuite, il y a le couche Modèle Objet du Document (en abréviation DOM en anglais) [Hors et al., 2004]. N’importe ce que la représentation est au sommet, à l’intérieur du navigateur cette représentation est un DOM. C’est la représentation unifiée de l’information que nous avons souligné comme une caractéristique fondamentale pour pouvoir mettre en œuvre un système conforme à notre approche. Dans certains cas (par exemple Firefox16 utilise XUL17) même le navigateur lui-même est un énorme DOM. Un aspect important sur le DOM est qu’il est complètement basé sur l’événement. Toute interaction, toute modification est signalée par un événement DOM [Pixley, 2000]. En conséquence, nous avons aussi la deuxième condition fondamentale, que nous avons identifiée alors qu’on enquêtait sur l’appareil TomTom. Une troisième couche est la Feuille du Style en Cascade (en anglais CSS) [Bos et al., 2010]. Cette couche applique le style. La quatrième couche est la représentation: soit une page web de base, un document XML, ATOM, etc. Le moteur de mashup est une boite comportant toutes ces couches. Ainsi, il a accès à chacun d’entre eux. Toute interaction, conversation, collaboration qui existe entre l’utilisateur, le navigateur et l’un des services en créant un mashup, est réalisé par des actions et des événements. L’ensemble des actions et des événements forment le comportement. L’utilisateur est représenté dans le système par l’intermédiaire de son comportement (actions et événements).
Le moteur de mashup représenté dans la figure 9 comporte un ensemble de capteurs et un en-semble d’actionneurs. Par les capteurs, le moteur perçoit les interactions et les communications avec l’environnement. Le moteur utilise des actionneurs pour modifier et / ou de communiquer de nouveau
16
http://www.mozilla.com/en-US/firefox/
17
CHAPTER 0. RÉSUMÉ ÉTENDU xxiii
avec l’environnement. L’environnement comprend un nombre arbitraire de services et de mashup, le navigateur et l’utilisateur (par ses interactions avec le système).
Chapitre 5 Résumé – Exécution
Ce chapitre concerne l’exécution d’une application Web suivant l’approche et le modèle conceptuel que nous avons introduit dans le Chapitre 3. Pour récapituler, l’exécution est fondée sur des règles et processus et est adaptée pour les navigateurs web.
Le Model Objet du Document ainsi que les Evénements DOM sont des interfaces neutres de plateforme et langage qui permettront aux programmes et scripts d’accéder de la façon dynamique et d’actualiser le contenu, la structure et le style des documents, et respectivement, permettent l’enregistrement des gestionnaires des événements, décrivent la circulation de l’événement par une structure type arbre et fournissent l’information contextuelle de base pour chaque événement.
Par conséquent, notre moteur d’exécution utilise directement ces interfaces neutres de plateformes et langage. Ainsi, notre moteur d’exécution est neutre du point de vue de la plateforme et du langage. En outre, nous pensons que grâce à la combinaison d’un moteur d’exécution basé sur des règles et l’utilisation de ces interfaces neutres des plateformes et du langage peuvent être atteints d’une approche unifiée et générique pour la définition et l’exécution de nouvelles applications définies de l’utilisateur final qui respectent entièrement la liste des exigences que nous avons identifié dans la section 2.6.
La composante de raisonnement d’un Système de Règles de Production standard est le Moteur d’Inférence (même dans notre cas). Le Moteur d’Inférence met en correspondance des faits et des données contre les règles de déduire des conclusions résultant des actions. Bien que les règles de production se composent de deux parties principales : (1) conditions et (2) actions, nous traitons principalement avec des règles de réaction ou des règles ECA qui comportent trois parties : (1) événement, (2) conditions et (3) actions. Les deux types de règles utilisent la logique du premier ordre pour la représentation des connaissances.
Le processus de mettre en correspondance de faits nouveaux ou existants contre les règles est appelé algorithme de corrélation et est effectuée par le Moteur d’Inférence. Notre implémentation est une variante de ReteOO qui aborde les systèmes orientés vers l’objet. Plus précisément, ceux basé sur la fermeture (JavaScript). En outre, il prend en charge par default les Evénements DOM.
Les règles pour notre système de règles sont stockées dans le plan défini par l’utilisateur (mashup). La mémoire de travail où toutes les faits résident de sorte que le Moteur d’Inférence peut les accède représente dans notre cas la structure DOM entière (toutes les services, pages web qui ont été associés avec les contextes dans le plan défini par l’utilisateur) o laquelle le Moteur d’Inférence a accès. Dans notre implémentation tous les faits se trouvent déjà dans la Mémoire de Travail. En outre, la Mémoire de Travail dans notre cas tient aussi les Evénements DOM, tant les événements DOM W3C prédéfinies (par exemple click, dblclick, mouseout, mouseover etc) ainsi que les événements DOM personnalisés. Toutes les interactions ont lieu à l’intérieur de la Mémoire de Travail. La mémoire de travail est en vie aussi longtemps que le mashup est activé dans le navigateur (cela signifie que tant que dans le navigateur web il y a un onglet ouvert dans le navigateur qui contient le mashup, la mémoire de travail sera maintenu en vie).
Il y a deux méthodes d’exécution pour le système des règles : le chainage avant et le chainage derrière. Notre implémentation est une implémentation à chainage avant.
Les règles sont écrites en employant la Logique du Premier Ordre (FOL en anglais), ou la logique des prédicats qui étend la logique propositionnelle. Les faits sont des objets (par exemple java beans, objets JavaScript). Ainsi, pour notre système de règles, les faits sont tous objets JavaScript auxquels le
xxiv
moteur a accès, c’est-à-dire tous objets de la Mémoire de Travail. Cependant, on n’emploie que les domaines des objets dans le procès de raisonnement, ou la structure statique d’un objet : propriétés (domaine, propriété ou attribut ont le même sens) et leurs valeurs. Puisque tous les éléments de notre modèle sont de Concepts, et en outre, un concept est une sous-classe de la classe uml::Class, puis l’un d’eux peut être faits. Dans les règles de conséquence pourrait être utilisé pour raisonner sur l’un d’eux d’une manière unifiée.
Une règle précise que sur l’événement attiré, si une série particulière des conditions intervienne, spécifié dans le côté gauche (LHS en anglais) alors on fait ainsi, étant mentionnée comme une liste des actions dans le côté droit (RHS en anglais). LHS est un nom commun pour la partie conditionnelle de la règle. Elle est constituée d’un zéro ou plusieurs éléments conditionnels. Les éléments conditionnels concernent les concepts, qui à son tour appartiennent aux contextes.
La condition (LHS) partie d’une règle peut comporter quelques éléments conditionnels. Nous envisageons une série d’éléments conditionnels pour notre langue d’exécution:
(1) un ConceptConditional, (2) un JavaScriptBooleanConditional, (3) un EqualityConditional.
L’élément conditionnel concernant les Concepts (ConceptConditional) est les plus important. Ce conditionnel est construit pour accommoder les objets et les caractéristiques des objets. Il décrit en fait la façon dont l’objet (le concept) devrait ressembler. Un objet (concept) comporte un type et propriétés (domaines). Par conséquent lorsqu’il s’agit d’un objet, dans notre cas, un concept, nous devons vérifier le type, nous avons besoin de pouvoir tester / contraindre les valeurs de propriétés et nous devons être en mesure de lier la valeur d’une propriété d’objet à une variable, de sorte qu’il puisse être utilisé plus tard dans un autre élément conditionnel d’une règle. En outre l’objet lui-même, pas seulement une propriété de celui-ci, peut être lié à une variable.
Conclusions
World Wide Web (WWW) est devenu le plus grand dépôt d’informations que l’homme ait jamais assemblé et il est en croissance continue. Le nouveau WWW ou l’Internet de l’Avenir est celui d’un Internet des Services et un Internet des Objets.
Naturellement, une série des questions se posent à partir de ce contexte : comment filtrez-vous les objets pour créer plus de valeur que vous obtenez actuellement ? Comment pouvez-vous regrouper les objets d’une manière intelligente et facile au lieu de la faire dans votre tête? Le monde ne peut pas être décrit sans ambiguïté, alors comment pouvez-vous permettre aux utilisateurs de traiter avec le monde à leur manière, en fonction de leur compréhension?
On a largement affirmé que la solution vient du droit des participants (utilisateurs finaux). Mal-heureusement, bien que beaucoup d’efforts ont été mis dans le développement d’un grand nombre de cadres à s’attaquer à certains des problèmes que ce nouvel environnement a apporté (on peut voir le chapitre 2), la conception et le déploiement d’un tel logiciel capable d’interaction directe et de l’autonomisation de l’utilisateur final est toujours un problème.
Notre objectif dans cette thèse est de combler ce manque d’outils qui sont capables d’une interaction directe et l’autonomisation des utilisateurs finaux, d’une façon unifiée. Pour atteindre cet objectif nous proposons une approche centrée sur l’utilisateur.
Pour son implémentation nous avons développé un modèle conceptuel pour cette approche, nous proposons une architecture qui est conforme à l’approche et nous avons aussi proposé un moteur d’exécution qui emploient règles ECA et les processus pour exécuter les applications que les utilisateurs finaux ont défini comme mushups.
CHAPTER 0. RÉSUMÉ ÉTENDU xxv
Nous soutenons que par l’approche discutée tout au long de cette thèse que nous avons beaucoup avancé vers une approche entièrement centrée sur l’utilisateur permettant aux utilisateurs finaux de créer leurs propres applications en utilisant Architectures Orientées vers les Services.
Nous envisageons quelques directions possibles pour étendre le travail que nous avons présenté et discuté au sein de cette thèse : (1) modélisation visuelle des plans définis par l’utilisateur ; (2) l’utilisation de l’approche des platesformes mobiles ; (3) ajout de différents types de raisonnement comme la programmation logique abductive.
De notre point de vue, le chaînon manquant nécessaire pour obtenir un système d’utilisateur final complet est une approche visuelle (sur la base de modèles de conception d’interaction) qui cachera complétement tous les autres aspects qui exposent encore des aspects techniques connexes, tels que le mashup, rédigé en un format JSON.
Chapter 1
Introduction
World Wide Web (WWW) has become the greatest repository of information that man has ever assembled and it is continuously growing. WWW transformed itself into a generative environment that fosters innovation through the advance of technologies and a shift in people’s perception of the Web and how they use it [Zittrain, 2008]. It "has shifted from transaction-based Web pages to interaction-based ones" [Ogrinz, 2009]. WWW changed radically, also the way knowledge is shared, by lowering the barrier for publishing and accessing documents [Bizer et al., 2010]. Moreover with the proliferation of Web APIs the Web has become a highly programmable platform [Aghaee et al., 2013].
The new WWW or Future Internet is that of an Internet of Services and Internet of Things. As described by SAP co-CEO Henning Kagermann [Kagermann, 2008],
The Internet of Services is largely based on a service-oriented architecture (SOA), which is a flexible, standardized architecture that facilitates the combination of various applications into inter-operable services.
The notion of a service is defined by Lovelock et al. [C. Lovelock, 1996] as
an act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production.
The first steps towards such an approach were made by proposing the notion of a Web service. A Web service is a form of a service. The notion of a Web service we use hereafter is provided by Sommerville [Sommerville, 2006]:
loosely coupled, reusable software component that encapsulates discrete functionality, which may be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet and XML-based protocols.
The concept of Service Oriented Architecture (SOA) is probably the most popular outcome of research in service based composition and has created a completely new way of composing existing functionality through dynamically binding and invoking services into a composite application. As stated in [Ogrinz, 2009], SOA is an evolutionary milestone and not a revolutionary one, where the understanding of a service in SOA is that of a business task. Such tasks are implemented in environments that facilitate loose coupling.
Yet, in reality, because of their still complicated technical nature, "Web services have hardly been adopted beyond the boundaries of enterprises" [Davies et al., 2009].
1.1. OBJECTIVE OF THIS THESIS 2
According to [O’Reilly, 2007], "Web 2.0 is the business revolution in the computer industry caused by the move to the Internet as a platform, and an attempt to understand the rules for success on that new platform". Web 2.0 technologies are interactive and require users to generate new information and content or to edit the work of other participants [Chul et al., 2009]. Chul et al. continue to state in [Chul et al., 2009] that, "the right solution comes from the right participants".
Naturally, a series of questions arise from this context: how do you filter things to create more value than you currently get? how do you aggregate things in an intelligent and easy way instead of doing it in your head? The world cannot be described unambiguously, so how can you allow users to deal with the world in their own way, based on their understanding? Levine in his book "Cluetrain manifesto" [Levine, 2009] was arguing that markets are conversations so how can users be involved in the conversation? how can users be empowered with easy consumption of the services, information, things that they found around?
By Levine [Levine, 2009], whether delivering information, opinions, perspectives, dissenting arguments or humorous asides, humans conversations are done typically in an open, natural, uncontrived manner. Future Internet (Web 2.0), has opened the ways towards enabling conversations among human beings that were simply not possible before.
However design and deployment of such software capable of direct interaction and empowerment of the end-user is still an issue. We have on one side users that have ideas, but do not have technical background and lack programming skills to do the development by themselves. On the other side, we have large amounts of data, resources and services that could be aggregated both in terms of data, but most important in terms of behavior to innovate and create new things. Nardi underlines this aspect clearly in [Nardi, 1993] stating that
"we have only scratched the surface of what would be possible if end users could freely program their own applications... As has been shown time and again, no matter how much designers and programmers try to anticipate and provide for what users will need, the effort always falls short because it is impossible to know in advance what may be needed... End users should have the ability to create customizations, extensions and applications..."
1.1
Objective of this thesis
Our goal in this thesis is to address this lack of tools that are capable of direct interaction and empowerment of end-users, in a unified manner. We are concerned specifically with Web based tools. We assert that for such web based user-centric systems, users, services (in the general form as defined in [C. Lovelock, 1996]), semantics and context, are key components of the system.
Context, as defined by Dey and Abowd [Dey et Abowd, 1999a]
is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and the applications themselves.
Lately, the notion of context has been considered not simply as state but as part of a process in which users are to be involved [Coutaz et al., 2005]. Context greatly influences the way humans or machines act, the way they report themselves to situations and things; furthermore, any change in context causes a transformation in the experience that is going to be lived [Bolchini et al., 2007]. Many psychological studies have shown that when humans act, and especially when humans interact, they consciously and unconsciously attend to context of many types as stated in [Grudin, 2001].
