L’INFORMATIQUE DIFFUSE

L’INFORMATIQUE DIFFUSE

Présentation de l’informatique diffuse

La notion de l’informatique diffuse a été proposée au départ comme une vision future de l’informatique par Mark Weiser (Weiser, 1991) suite à son analyse du marché mondial des ordinateurs et des équipements informatiques . Il a remarqué une croissance énorme du nombre d’ordinateurs : un ordinateur pour plusieurs utilisateurs, puis un ordinateur par utilisateur ensuite, plusieurs ordinateurs par utilisateur en utilisant l’intégration des processeurs dans des objets de la vie quotidienne (systèmes embarqués). Cette nouvelle forme de l’informatique qu’il a nommée informatique ambiante (en anglais “ubiquitous computing”) et dont l’objet viserait à assister implicitement et discrètement un utilisateur dans les tâches qu’il accomplit au quotidien, devenant ainsi la base des systèmes informatique diffus (Cliquet, 2007).

L’évolution technologique actuelle rend aujourd’hui la vision de Mark Weiser réaliste à la suite de l’apparition des nouveaux systèmes embarqués ayant des tailles de plus en plus petites et enfouis dans différents objets de la vie quotidienne. L’avènement des réseaux de communications sans fil avec les standards de télécommunication, tels que GSM, GPRS, UMTS, particulièrement utilisés pour la téléphonie mobile, mais également avec l’apparition de WiFi, RFID et Bluetooth pour les équipements informatiques et particulièrement pour les terminaux informatiques mobiles tels que les assistants personnels (PDA : personal digital assistant) et les téléphones cellulaires,(resp. iPhone), a permis à ces équipements de communiquer (profil matériel, contexte, etc.) pour coopérer.

Modélisation et simulation

Afin de franchir une étape importante vers la validation de notre architecture, nous avons réaliser sa modélisation et sa simulation (Miraoui, Tadj et Amar, 2009) afin d’évaluer un certain nombre de ses aspects en décrivant le comportement de ses composants et de leurs propriétés. Nous avons utilisé les réseaux de Petri colorés (RdPC) comme formalisme de modélisation et le CPN-Tools comme outil de simulation et d’évaluation. Plusieurs méthodes d’évaluation des architectures logicielles selon des qualités désirées ont été proposées (Babar et Gorton, 2004; Kazman et al., 1996; Mattsson, Grahn et Mårtensson, 2006). Parmi ces méthodes, nous pouvons citer celles qui sont basées sur les expériences, les simulations, les scénarios et la modélisation mathématique.

Ces méthodes peuvent être utilisées séparément ou combinées pour obtenir de meilleurs résultats. Il est fortement recommandé de faire l’évaluation des performances tôt au niveau de la conception architecturale, en développant et en évaluant un modèle de d’architecture logicielle qui aide à comprendre la fonctionnalité du système, ses possibilités et sa complexité. L’identification des problèmes de performance au niveau de la conception architecturale est très utile et plus rentable (économique) parce qu’elle évite de changer la conception plus tard (Balsamo et Marzolla, 2003). L’utilisation des méthodes formelles pour modéliser et décrire le comportement du système à un niveau élevé d’abstraction peut contribuer à la consistance et à la fiabilité de la conception architecturale, facilitant ainsi le procédé de validation.

Scénario d’application

Pour mettre en évidence la clarté, la cohérence et l’employabilité de notre ontologie de service, nous allons présenter dans ce chapitre un scénario d’application. Dans ce scénario, l’équipement informatique est un téléphone cellulaire. Nous montrons dans ce qui suit les quatre principales étapes à suivre afin de modéliser le contexte pour un service particulier. Les mêmes étapes peuvent être suivies pour tout autre service.

spécification des services Dans le cas général, le processus de modélisation commence en spécifiant pour chaque équipement informatique du système diffus, l’ensemble des services qu’il peut fournir. Dans notre scénario, nous allons prendre, comme exemple de service fourni par un téléphone cellulaire, l’indication des appels entrants (modélisation d’informations contextuelles pour un équipement et un service particulier).

spécification des formes de services Cette étape du processus de modélisation consiste à spécifier pour chaque service, l’ensemble de formes sous lesquelles, le service peut être fourni. Dans notre cas et par défaut, le téléphone cellulaire indique des appels entrants en employant des sonneries (forme par défaut) mais pour une raison ou une autre, il peut indiquer les appels entrants sous d’autres formes comme suit :

Vibreur : quand l’utilisateur (nous supposons qu’il est un étudiant) est dans la bibliothèque de l’université (pour éviter de déranger d’autres étudiants et de respecter les consignes) ou dans une salle de classe (les heures d’étude sont extraites de l’emploi de temps de l’étudiant.

Sonneries avec vibreur : quand l’utilisateur est dans un endroit bruyant, cette forme sera employée pour attirer l’attention de l’utilisateur .

Silencieux : quand l’utilisateur dort (nous supposons que l’utilisateur dort habituellement de minuit à 8 h et son environnement est obscure avec faible bruit).

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
CHAPITRE 1
1.1Présentation de l’informatique diffuse
1.2Exemple de scénario
1.2.1Scénario
1.2.2Analyse du scénario
1.3Avantages et inconvénients de l’informatique diffuse
CHAPITRE 2 CONTEXTE ET SENSIBILITÉ AU CONTEXTE
2.1Définitions générales
2.2Définitions du contexte dans un système informatique
2.2.1Définitions antérieures
2.2.2Notre définition orientée service du contexte
2.3Définitions antérieures de la sensibilité au contexte
2.3.1Notre définition de la sensibilité au contexte
2.4Utilisation du contexte
2.5Sources d’informations
2.6Catégorisation du contexte
2.6.1Notre catégorisation du contexte
2.7Qualité de l’information contextuelle
CHAPITRE 3 ARCHITECTURE POUR LES SYSTÈMES SENSIBLES AU CONTEXTE
3.1Travaux connexes
3.1.1ActiveBadge (1992)
3.1.2ParcTab (1995)
3.1.3Stick-e-notes (1997)
3.1.4Cyberguide (1997)
3.1.5CASS (2004)
3.1.6CORTEX (2004)
3.1.7Context management framework (2003)
3.1.8JCAF (2005)
3.1.9Context Toolkit (2001)
3.1.10Hydrogen (2003)
3.1.11SOCAM (2004)
3.1.12CoBrA (2004)
3.2Analyse des architectures antérieures
3.3Architecture multiagents orientée service
3.4Discussion
3.5Modélisation et simulation
3.5.1Les réseaux de Petri colorés et le CPN-Tools
3.5.2Modélisation et simulation de l’architecture
CHAPITRE 4 MODÉLISATION DU CONTEXTE
4.1Travaux connexes de modélisation du contexte
4.1.1Approches non ontologiques
4.1.2Approches ontologiques
4.1.3Analyse des modèles ontologiques antérieurs
4.2Proposition d’une ontologie de service
4.3Scénario d’application
CHAPITRE 5 ADAPTATION DE SERVICES SELON LE CONTEXTE
5.1La notion d’adaptation
5.2Approche d’adaptation fondée sur un apprentissage automatique
5.2.1Méthodologie
5.2.2Scénario d’application
5.3Approche d’adaptation sensible aux ressources limitées
5.3.1Méthodologie
5.3.2Modélisation et simulation
CONCLUSION