JY Tigli Homepages

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.

====== Mon PLAN HDR  ======

===== Titre =====

Intergiciel pour l'Informatique Ambiante 


==== Introduction : ====

  * Rappel sur l'histoire de l'Informatique comme Science (Cf. Berry)
  * Où placer la notion de Middleware  ? (Cf. Tigli / Fête de la Science)
  * Objectif : Masquer et gérer la distribution = déjà idée de maintenir un modèle idéal du système au runtime fonction d'une infrastructure contrainte. (Sacha Krakoviak)

Domaine de la HDR :

  * Intergiciel au sens large du terme : fournir une couche entre applicatif et système pour fournir un modèle idéal du système au runtime. 

  * Pour les systèmes interagissant avec l'environnement physique, depuis les robots jusqu'à l'Informatique Ambiante  la diversité sémantique des dispositifs d'E/S est par exemple maintenant de mise => l'intergiciel est en charge de gérer cette diversité.

==== Les intergiciels : ====

=== Informatique distribuée et Intergiciels : Etat de l'Art ===

Message :  Basé sur une définition restreinte de la notion d'intergiciel = masquer la distribution et les communications réseaux

=== Informatique Ambiante et Intergiciels : ===

Message : Basé sur une définition plus générale d'intergiciel =
  * démarche bottom-up au service des démarches top-down (fournir un modèle intermédiaire idéal masquant les limitations des ressources) 
  * Problématique non limitée à la distribution, mais applicable à la gestion de toute ressource : ex. réseau / écran / mémoire / cpu / pointeur-souris /moteurs en robotique.... à la recherche d'une mise en oeuvre transparente et simplifiée de ces ressources, pour gérer les accès concurrent à des ressources limitées voire non duplicables.
  * En fait ressources = tous les éléments de Von Neuman CPU / MEM / I-O 


Nouveaux challenges :

  * Mobilité, Ubiquité, Utilité (Cf. Gordon Blair) 
  * Hétérogénité de ces ressources (technologique et sémantique) => gestion des accès concurrents 

1> 
Aujourd'hui des  blocs distincts et/ou organisés en couche : OS / Runtime Graphique / Middleware Réseau / Contexte ...

Pourtant la non interaction autre qu'applicative (en bloc) ou la hiérarchie  (en couche) entre ces middlewares ne sont aproprié. Exemple (thèse hourdin) le contexte peut tout autant influencer les fonctionalités offertes par un middleware réseau que le middleware réseau intervenir dans la gestion du contexte.

Séparation des préocuppation OK mais entrelacement (tissage).

2> 
Chaque ressource est alors associée à un gestionnaire ayant pour objectif de garantir le comportement de la ressource  en cas d'accès multiples et concurrents. (travaux avec Annie Ressouche, vers des proxies prouvés)


  * Variabilité ou Dynamicité de ces ressources => adaptation au variation


== systèmes interagissant avec l'environnement physique ==

  * Introduction  Réprésentation / Traitement / Comportement ?

  * Approche classique en Informatique : Données ou Information / Traitement ou Algorithmique 
     L'environnement est alors perçu au travers des données représentatives et rafraichies. Sauf dans quelques cas extrêmes (Temps Réel par exemple), le comportement temporel de l'application est souvent prise en compte tardivement dans une phase d'optimisation. Cela est acceptable dans la mesure où de telles  optimisations et évolutions des performances matérielles peuvent répondre à l'amélioration du comportement temporelle de l'application. Il est pourtant  bien des cas  ou la complexité croissante et mal maitrisé de la collecte et du  traitement de l'information rende cette quête vaine. Il est  dans ce cas important de garantir au système la capacité de réagir avec des temps de réponses acceptables et appropriés  quitte à réduire l'étendue des données collectées et la complexité des traitements mis en jeux.

   * décomposition comportementale en informatique : 
Ce constat inspire une démarche appelée décomposition comportementale de l'application. Elle consiste à limité la collecte de  l'information et son traitement pour l'accomplissement du seul comportement que l'on veut que le système adopte.  Il s'agit alors de composer de tels entités tout en maitrisant leurs interactions.

Cette démarche à largement fait ses preuves en Robotique. 

Définition du comportement : 
par Wiener Norbert (en définissant la notion de cybernetique) : "boucle fermée permettant d'évaluer les effets de ses actions et de s'adapter à une conduite future grâce aux performances passées". 

==== Vers un modèle de middleware pour l'informatique ambiante ====


=== Un Modèle de Système d'Informatique Ambiante ===


=== Un Modèle d'une Infrastructure Logicielle pour l'IAm ===


=== Composition Dynamique pour l'IAM ===

== Composition Dynamique local ==

  * LCA (le middleware n'est plus dédié à la distribution, il est même nécessaire de la rendre explicite en IAm) 

== Composition Dynamique distribuée ==

== limitations ==

  * la complexité des modifications dynamiques à produire pour adapter le système à l'évolution du contexte est trop importante
  * la fréquence des modifications dynamiques à produire pour adapter le système à l'évolution du contexte est trop importante
  * Il nous faut donc un mécanisme d'autoadaptation

=== Autoadaptation basée sur des Aspect ===

== Etat de l'art sur la reflexivité ==


Cf. livre Middleware
Cf. Adaptation Dynamique Model at Runtime 
Cf Benomo

Problème commun réduire la complexité des adaptations 
Les Ecoles :
- MOP (reflexivité)
- Aspects classiques  
- Policy based ...
- concept-based
- Multi-agent ... 
- Model at Runtime et AOM 

== Principes de notre Approche ==

== Les Aspects d'Assemblage == 

== Réduction de la complexité == 

* Perspective : End User programming 

== Réactivité et Performances  ==


==== Conclusion et Perspectives ====


==== Annexes : ====
  * CV

====== NOTES sur TOPICS ======

===== Subsomption =====

Le principe de subsomption (subsumption) promu par Brooks pour sa décomposition comportementale définit  par nature une relation héirarchique entre ces comportements. En effet la notion de subsomption se définti ainsi  (Cf. http://fr.wikipedia.org/wiki/Subsomption) : La subsomption désigne une relation hiérarchique entre des concepts, dans les logiques de description. Cette notion est proche de la relation « est impliqué par » en logique classique, ou encore « contient » en logique ensembliste. (La relation de subsomption permet de construire un treillis de Galois à partir d'un ensemble d'individus et de propriétés.)

Exemples:
    * Le concept HUMAIN subsume le concept FONCTIONNAIRE .
    * Le concept ELECTEUR est subsumé par le concept MAJEUR .

de même que pour Brooks un comportement de haut niveau comme chercher une boîte dans l'environnement du robot subsume un comportement de plus bas niveau comme  éviter les obstacles autour du robot.


===== Composant versus Service =====

== Un service à une Instance unique : ==
A la différence des composants qui sont instanciés à la demande et peuvent avoir plusieurs instances en même temps, un service est unique. Il correspond au design pattern Singleton. (Cf. http://fr.wikipedia.org/wiki/Architecture_orient%C3%A9e_services#Le_service)


== Composant ==

Un composant est un élément de base d'un ensemble plus complexe (structuré ou composite), lequel est un assemblage de composants souvent différents. (Cf. http://fr.wikipedia.org/wiki/Composant)

http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_composant


A LIRE : http://www.irisa.fr/triskell/publis/2004/Jezequel04b.pdf (historique des paradigmes logiciels) 

A LIRE : http://blog.xebia.fr/2009/06/04/soa-du-composant-au-service-sans-etat-stateless/ (composant versus service et statelessness)

A LIRE :http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles (Statelessness) 


===== Autres PLANS de HDR  =====

[[http://membres-liglab.imag.fr/donsez/pub/publi/hdr/HDR-DidierDonsez-Manuscrit.pdf|Didier Donsez]]

[[http://bib.gdr-isis.org/1381/01/HDR.pdf|Christophe Légers]]


[[http://hal.archives-ouvertes.fr/docs/00/43/91/34/PDF/hdr.pdf|Lionel Seinturier]]

[[http://liris.cnrs.fr/Documents/Liris-3409.pdf|Frédéric Laforest]]

[[http://www2.lifl.fr/~rouillar/HDR/HDR_ROUILLARD_FINALE.pdf|Rouillard]]

[[http://hal.archives-ouvertes.fr/docs/00/04/61/29/PDF/tel-00004696.pdf|Laurence Nigay]]

[[http://users.polytech.unice.fr/~blay/HabilitationBook.pdf.zip|Mireille Blay]]

[[http://users.polytech.unice.fr/~helen/publis/habilitation.pdf|Hélène Collaviza]]

[[http://www.i3s.unice.fr/~mirbel/hdr/memoire-hdr-im.pdf|Isabelle Mirbel]]

[[ftp://ftp.irit.fr/IRIT/IHCS/HDR_Dubois2009.pdf|Emmanuel Dubois]]

===== Titre =====
JY Tigli Homepages

Outils pour utilisateurs

Outils du site

Outils de la page
