Page ‹#› 1

(1)

DEA SIR -- Conception d’Applications Concurrentes

Jean-Pierre Briot 1

DEA Systèmes Informatiques Répartis Tronc CommunConception par Objets et Prototypage d’Applications Concurrentes

Adaptation Logicielle : Réflexion, Composants, Agents

Copie transparents en :

http://www-poleia.lip6.fr/~briot/cours/adaptation-sir03-04.pdf

Jean-Pierre Briot Thème OASIS

(Objets et Agents pour Systèmes d’Information et Simulation) Laboratoire d’Informatique de Paris 6

Université Paris 6 - CNRS Jean-Pierre.Briot@lip6.fr

Jean-Pierre Briot 2

Besoins d'Adaptation du Logiciel

• Nouvelles applications informatiques :

– (informatique nomade, objets communicants, travail coopératif, multimedia, etc.)

• Profonds besoins en matière de dynamicité : – dynamicité des services offerts,

– adaptation à des environnements et contraintes d'exécution évoluant dynamiquement (et éventuellement non prédictibles),

» ex : contraintes de débit,

» de taille

» de sécurité

» de robustesse

» de ressources

» de qualité de service...

Jean-Pierre Briot 3

Problématique de l'adaptation du logiciel

• Adaptation (statique et dynamique) individuelle – Réflexion

• Adaptation d'un ensemble de logiciels (recomposition) – Composants

• (vers une) Auto-Adaptation logicielle – Agents

Jean-Pierre Briot 4

I - Réflexion

Jean-Pierre Briot 5

(Retour à un vieux) Dilemne

• Ecrire de BEAUX programmes – lisibles

– concis – modulaires – abstraits – génériques – réutilisables

• Ecrire des programmes EFFICACES – spécialisés

– choix optimaux de représentation interne des données – contrôle optimisé

– gestion des ressources adéquate

• DILEMNE : Spécialiser/optimiser des programmes tout en les gardant génériques

Jean-Pierre Briot 6

Boîte noire

Modèle

Programme

Interprète / Compilateur / Moniteur Boîte noire

Mise en oeuvre (exécution) du programme est non modifiable exécuté par

(2)

Jean-Pierre Briot 7

Solutions Ad-Hoc

• Coder "entre" les lignes – difficile à comprendre

– difficile à maintenir (hypothèses cachées) – peu réutilisable

• Annotations/Directives (déjà mieux) – ex : High Performance Fortran (HPF) – mais

» notations de plus ou moins bas niveau

» ensemble/effet des annotations non extensible/adaptable

Jean-Pierre Briot 8

Réflexion (3)

Modèle

Programme

Interprète / Compilateur / Moniteur

Boîte semi-ouverte (méta-interfaces)

Mise en oeuvre (exécution) du programme est adaptable/spécialisable exécuté par

Open Implementation [Kiczales 94]

Jean-Pierre Briot 9

Réflexion

• Le concept de réflexion (méta-programmation, architectures réflexives...) offre ainsi un cadre conceptuel permettant un découplage des fonctionnalités d'un programme des caractéristiques de sa mise en œuvre

Jean-Pierre Briot 10

Réflexion (2)

• Diverses caractéristiques de représentation (statique) et d'exécution (dynamique) des programmes sont rendues concrètes (réifiées) sous la forme de méta-programmes.

– Habituellement elles sont invisibles et immuables (interprète, compilateur, moniteur d'exécution...)

• La spécialisation de ces méta-programmes permet de particulariser (éventuellement dynamiquement) l'exécution d'un programme

» représentation mémoire

» modèle de calcul

» contrôle de concurrence

» séquencement

» gestion des ressources

» protocoles (ex : résistance aux pannes)

avec le minimum d’impact sur le programme lui-même

Contexte d’exécution

programme représentation

mémoire séquencement

synchronisation répartition

Réification/réflexion

niveau objet (application)

niveau implémentation niveau meta (réification d’une partie du niveau implémentation)

niveau objet

application

implémentation de l’application (caractéristiques et contrôle cachés)

réification réflexion

?

? ?

(3)

Réification/réflexion

• Réification numérique (potentiomètres) – Ex : Options de compilation d’un compilateur

•

• EfficacitEfficacitéé vs taille vs taille du code généré

niveau objet

application

Réification/réflexion (2)

• Réification logicielle (méta-programmes) – Ex : algorithme de séquencement (scheduler)

niveau objet

application

plus général/flexible que des potentiomètres méta-programme par défaut

(ex : séquenceur préemptif)

méta-programme spécialisé (ex : séquenceur temps réel)

Réflexion (4)

• Découplage des fonctionnalités d'un programme des caractéristiques de sa mise en œuvre (exécution)

• Séparation entre programme ET méta-programme(s) favorise : – généricité et réutilisation des programmes

– et des méta-programmes

• Ex :

– changer la stratégie de contrôle pour un programme donné – réutiliser une stratégie de contrôle en l'appliquant à un autre programme

Structure / Dynamique

• Structure (représentation) – spécialiser la création des données

» méthodes de classe (= méthodes de métaclasses) en Smalltalk

» constructor member functions en C++, en Java – spécialiser un gestionnaire de fenêtres

» implantation d'une feuille de calcul en Silica [Rao]

– introspection

» représentation d'entités du langage Java (ex : entiers, classes) sous forme d'objets Java

• Dynamique (comportement/exécution)

– implémenter des coroutines via la manipulation de continuations

» call/cc en Scheme – spécialiser le traitement d’erreur

» doesNotUnderstand: en Smalltalk

– changer l'ordre de déclenchement de règles de production

» méta-règles en NéOpus

Approche réflexive

• Réflexion permet d'intégrer intimement des (méta-)bibliothèques de contrôle avec un langage/système

• Offre ainsi un cadre d'interface entre approche applicative et approche intégrée

• La réflexion s'exprime particulièrement bien dans un modèle objet – modularité des effets

– encapsulation des niveaux

• méta-objet(s) au niveau d'un seul objet

• méta-objets plus globaux (ressources partagées : séquencement, équilibre de charges...)

–group-based reflection [Watanabe’90]

Méta-objets/composants

• CodA [McAffer ECOOP'95] est un exemple de modèle relativement général d'architecture réflexive

• Sept méta-objets/composants de base : – envoi de message

– réception de messages – stockage des messages reçus – sélection du premier message à traiter – recherche de méthode correspondant au message – exécution de la méthode

– accès à l'état de l'objet

• Les méta-composants sont : – spécialisables – (relativement) combinables

(4)

CodA

A B

accès état réception

stockage sélection recherche

exécution envoi

Ex : Exécution concurrente

– envoi de message – réception de messages –stockage des messages reçus

» file d'attente (FIFO) – sélection du premier message à traiter – recherche de méthode correspondant au message –exécution de la méthode

» processus associé

» boucle infinie de sélection et traitement du premier message – accès à l'état de l'objet

Exécution concurrente (2)

A B

Ex : Exécution répartie

–envoi de message

» encodage des messages, envoi via le réseau –réception de messages

» réception via le réseau, décodage des messages – stockage des messages reçus

– sélection du premier message à traiter – recherche de méthode correspondant au message – exécution de la méthode

– accès à l'état de l'objet

–encodage

» discipline d'encodage (marshal/unmarshal) –référence distante

–espace mémoire

Exécution répartie (2)

A B

exécution envoi réseau

Exécution concurrente et répartie (composition)

A B

exécution envoi réseau

(5)

Temps réel

• méta-acteurs associés à des acteurs – contrôle du temps pour du «soft real time» [Honda’92]

• machine de contrôle [Nigro et al., FMOODS’97] pour un ensemble d’acteurs – méta-composants :

» horloge, queue de messages (= liste d’événements), contrôleur (période de simulation), séquenceur

» permettent de modifier les aspects temporels de l’application indépendamment de l’application elle-même

» ex : simulation distribuée optimiste (Time Warp) de réseaux de Petri temporels (timed Petri nets)

région queue de messages

séquenceur schedule

dispatch

transition

processus logique mark enabling

firings topology

Réflexion sur un ensemble d’objets Ex : Installation d’un protocole de réplication passive

Serveur Requêtes Réponses

Client Client

Serveur Requêtes Réponses

Réplication passive

Instance du protocole de réplication passive

«backup»

du serveur

Rôle

"répliqué"

Assignations de rôles

Rôle

"réplica"

COMET [Peschanski ’99]

Systèmes commerciaux

• Muse (ex-Aperios) [Yokote OOPSLA'92]

– spécialisation dynamique de la politique de séquencement (ex : passer au temps réel) – application au «video on demand» et aux robots-chiens Aibo (Sony)

• Moniteur de transaction [Barga et Pu '95]

– Incorporation de protocoles transactionnels étendus (relâchant certaines des propriétés standard : ACID)

– dans un système existant – réification a posteriori via des upcalls

» (délégation de verrou, identification de dépendances, définition de conflits)

Moniteur de transaction rendu réflexif/ouvert

méta-composants

Exemple : CORBA

• approche réflexive

– réification de certaines caractéristiques de la communication

» ex : smart proxies de Orbix (IONA)

• ex d’utilisation : implantation de transmission de messages asynchrone

• intégration des services avec la communication distante

Bilan - Conclusion

• Approche réflexive prometteuse

• Architectures réflexives encore plus ou moins complexes, mais méthodologie s'établit et s'affine

• Validations en vraie grandeur en cours

• Retour du problème clé de la composition arbitraire (de méta- composants)

• (In)Efficacité

– réduction de la portée de la réflexion (compilation)

» ex : OpenC++ version 2 [Chiba, OOPSLA’95]

– transformation de programmes - évaluation partielle

» [Masuhara et al., OOPSLA’95]

• Ne dispense pas du travail nécessaire à l'identification des bonnes abstractions

(6)

II - Composants

• granularité encore trop fine-moyenne – pas trop bien adapté à la programmation à grande échelle

• pas encore assez modulaire – références directes entre objets

– donc connexion non reconfigurable sans changer l’intérieur de l’objet

» objet appelé

» nom de la méthode appelée

(Limites) des objets...

x x

méthA ? méthA

méthB

?

... aux composants

Idées :

• composants – plus «gros»

– plus autonomes et encapsulés

– symétrie retrouvée : interfaces d’entréeS mais aussi de sorties – plusieurs interfaces de sortie, et d'entrées : notions de "bornes"

• réification des relations/connexions entre composants – références hors des objets -> couplage externe (mais reste explicite) – notion de connecteur

composant

borne

connecteur

Architectures logicielles

• Programmation à grande échelle

• Configuration et reconfiguration d’applications modulaires/réparties

• Composants

– clients, serveurs, filtres, couches...

• Connecteurs

– appels de procédure, messages, diffusion d’événements, pipes&filters...

composant connecteur

Architectures logicielles

[Shaw et Garlan 96]

• différents types d’architectures (styles architecturaux) – pipes & filters, ex : Unix Shell dvips | lpr – couches, ex : Xinu, protocoles réseaux – événements (publish/subscribe), ex : Java Beans – frameworks, ex : Smalltalk MVC

– repositories, ex : Linda, blackboards

• un même (gros) système peut être organisé selon plusieurs architectures

• les objets se marient relativement bien avec ces différentes architectures logicielles

– objets et messages comme support d’implémentation des composants et aussi des connecteurs

– cohabitation, ex : messages et événements

Ex1 : Pipes & filters

• Composants : filters

• Connecteurs : pipes

• Ex : Unix shell dvips | lpr

• +

» compositionalité (pipeline)

» réutilisabilité

» extensibilité

» analyses possibles (débit, deadlock...)

» concurrent

• -

» «batch», pas adéquat pour systèmes interactifs, ex : interfaces homme-machine

» petit dénominateur commun pour la transmissiond e données

• performance

• complexité

(7)

Ex2 : Objets & messages

• Composants : objets

• Connecteurs : transmission de messages

• Ex : Java

• +

» encapsulation

» décomposition

• -

» références directes

• nécessité de recoder les références si reconfiguration

Ex3 : Diffusion d’événements (publish/subscribe)

• Composants : modules

» interfaces :

• procédures

• événements

• Connecteurs : diffusion d’événements

• Ex : interfaces homme machine, bases de données (contraintes d’intégrité), Java Beans

• +

» réutilisation

» évolution

• -

» contrôle externe aux composants

• difficile de déterminer quels modules seront activés, dans quel ordre...

» validation difficile événement annoncer/diffuser

un événement s’abonner à

un événement

Ex4 : Systèmes en couches (layered systems)

• Composants : couches

• Connecteurs : appels de procédures

• Ex : protocoles de communication/réseaux, bases de données, systèmes d’exploitation (ex : Unix)

• +

» niveaux croissants d’abstraction

» extensibilité

» réutilisabilité

• -

» pas universel

» pas toujours aisé de déterminer les bons niveaux d’abstraction

» performance

abstrait

concret/matériel

client

service

Ex4 : Repositories

• Composants : – structure de données centrale – processus

• Connecteurs : accès directs processus <-> structure – processus -> structure, ex : bases de données – structure -> processus, ex : démons, data-driven/trigger

• Ex : (Linda)Tuple space, blackboard (tableau noir)

• +

» partage des données

• -

» contrôle opportuniste

Tuple space

Comparaison de styles architecturaux

• Exemple d’application :

– (architecture de contrôle d’un) robot mobile autonome

• Propriétés/caractéristiques recherchées : – comportement à la fois délibératif et réactif – perception incertaine de l’environnement – robustesse (résistance aux pannes et aux dangers) – flexibilité de conception (boucle conception/évaluation)

caméra infra rouge capteurs

moteurs roues moteur tourelle

actionneurs

Solution 1 - boucle de contrôle

contrôleur

actionneurs capteurs

environnement

action feedback

(8)

Solution 2 - couches

superviseur

planification globale

contrôle

navigation

modélisation monde réel

intégration capteurs

interprétation capteurs

contrôle robot

environnement

Solution 3 - (tâches et) événements

tâche tâche

tâche envoi message

système de messagerie signalement

exception

tâche diffusion message

tâche tâche

espionnage

collecter pierre

prendre pierre

lever pierre se

déplacer

tourner à

gauche avancer

Solution 4 - tableau noir

navigation supervision

perception

tableau noir

pilotage

perception de bas niveau

Comparaison

Boucle de

contrôle couches événements tableau noir coordination

des tâches + - - + + +

incertain - + - + - +

robustesse + - + - + + +

sûreté + - + - + + +

performance + - + - + + +

flexibilité + - - + +

• Architecture Description Languages (ADLs) – définition des composants

• deux types d!’interfaces : – requises (in) – fournies (out) – sémantique d’appel

– synchrone – asynchrone/événement – définition des connexions

• connecteurs utilisés (ex : RPC) – vérification de la sémantique d’assemblage

• conformité types/interfaces

• contraintes de déploiement (OLAN) – ex : taille mémoire minimale, charge machines, etc.

– Unicon [Shaw et al. 95]

– Rapide [Lucham & Vera 95]

– OLAN [Belissard et al. 96]

Langages de description d’architectures

plus sur les ADLs (et le reste)

• Transparents de cours Ecole d’Eté sur la Construction d'Applications Réparties IMAG-INRIA-LIFL

• http://sirac.imag.fr/ecole/

– 1998 – 1999

• En particulier sur les ADLs (exemples en Unicon, OLAN, Rapide...) : – http://sirac.imag.fr/ecole/98/cours/composants.pdf

– transparents de Michel Riveill – pages 3-4 et 27-43

– également http://sirac.imag.fr/ecole/99/cours/99-8.pdf – et tous les autres transparents !

• http://sirac.imag.fr/ecole/98/cours/

• http://sirac.imag.fr/ecole/99/cours/

(9)

transparent de Michel Riveill

Composants

• Un composant est du code exécutable et son mode d!’emploi – module logiciel autonome (et persistant)

– exporte interfaces (d'entrée et de sortie) – auto-description

– «!composable!»

• Composants «!source!»

– architectures logicielles – ex : Sun!JavaBeans

• Composants binaires – ex : Microsoft COM

• «!Petits!» composants – ex : composants graphiques JavaBeans

• «!Gros!» composants – ex : MS Word, ILOG Solver...

(10)

Pourquoi les composants ?

[Albert et Haren 2000]

• Analyse sur + de 2000 clients de composants (ILOG et autres) – 11 Critères pour l!’application développée (à base ou pas de composants) :

• flexibilité offerte (éventail de choix ou forte rigidité) – ex : fenêtres rondes rares et difficiles à intégrer – peut brider l’imagination des architectes

• compétences requises (communes ou rares/pointues) – conception vs utilisation

• moyens nécessaires au projet (incluant déploiement et maintenance) + coût de développement important, + composants avantageux

• vitesse de développement

– excellente avec composants, ex : presque indispensable aux startups – mais adaptation composants peut être difficile

• incrémentalité du développement

– porte sur l’extension de certains composants du prototype

• fiabilité du résultat

– composants améliorent toujours fiabilité (capitalisation des tests) – mais (factorisation fait que la) criticité des composants augmente

Pourquoi les composants ?

(2)

• performance du résultat final

– performance en général inversement proportionnelle à généricité – mais capitalisation de l’optimisation

• facilité de déploiement (portabilité sur différentes plates-formes) – capitalisation des portages

– utilisation quasi-générale pour les IHM

• indépendance vis-à-vis des fournisseurs (possibilités de migrer d’un fournisseur à un autre, absorber la disparition ou rachat par compétiteur...)

– actuellement interfaces encore souvent propriétaires

– pérennité du contrat avec fournisseurs de composants vs grand turnover développeurs internes

• lisibilité du code source

– interne : découpage forcé en composants l’améliore – externe : API documentées facilite lisibilité du logiciel métier

• répétabilité du processus (réutilisabilité code-source, savoir-faire, équipe...) – capitalisation de l’apprentissage de l’utilisation de composants

COM / DCOM / ActiveX

(d’après Peschanski&Meurisse)

• COM : Component Object Model

• Définition d'un standard d'interopérabilité de Composants binaires – Indépendant du langage de programmation (i.e VB et C++ ?) – Modèle de composants extrêmement simple (voire vide...)

– notion de composition de composants limité à la notion d'interface (containment / aggregation)

• But : fournir un modèle à base de composants le plus simple possible permettant l'adaptabilité, l'extensibilité, la transparence à la localisation (in process, local, remote) et des performances optimums...

Principes de COM

• Encapsulation "totale"

– Black-Box : chaque composant est vu comme une boîte noire – L'interopérabilité entre composants ne se fait que via leurs interfaces – Possibilité de définir des interfaces multiples pour un même composant – QueryInterface : 'découvrir' les interfaces en cours d'exécution

(réflexion !!)

– IUnknown : gestion du cycle de vie des composants (GC)

COM Object

IUnknown

Interface2 Interface1

La composition dans COM

IUnknown knows A, B and C

B A

C D

IUnknown Composant1

Composant2

Par confinement / délégation

IUnknown knows A, B, C and D

B A

C D

IUnknown Composant1

Composant2

Par agrégation

Principes de 'Réutilisabilité' [Microsoft97]

Cycle de vie des composants ('Versioning')...

JavaBeans

• Motivations : Composition graphique d'applications

• Définition :

– Entité logicielle manipulable graphiquement

– “A Java Bean is a reusable software component that can be manipulated visually in a builder tool.” [Sun Spec97]

• "Modèle" inspiré des Architectures logicielles

• mais principalement orienté implémentation...

(11)

Communication des JavaBeans

Push button

Inspiré d'un style architectural : Communication implicite

(

publish/subscribe

)

Vector listeners

public synchronized addListener (Listener l)

Emetteur

handleEvent (Event e)

Emetteur.addListener (this) Récepteur

event

Propriétés JavaBeans

• Propriétés

• attributs, ex : couleur, taille, position...

• peuvent être accédés de l'extérieur

• convention de nommage des méthodes d'accès

• int i getX et setX(int i)

• peuvent être "liées" (déclenchement d'événements notification)

• Introspection granularité méthode/attribut

• Déploiement - Packaging (JAR)

• Support de Sérialisation Beans - Evénements

• etc.

• But : Simplifier le développement d'architectures "3 tiers", côté serveur

Enterprise JavaBeans

Client

Logique Système Logique

métier Logique

métier Composants

Conteneur Serveur

Base de données, Moniteur transactionnel, etc Troisième tiers

• Développement -> "contrats"

• Déploiement

• Persistance

• Sécurité

• Transactions -> "déclaratif"

• Packaging -> "ejb-jar"

Composants Corba : modèle abstrait

Modèle abstrait

Interface2 i2 Interface1 i1

Interface3 i3

Property1 p1 Property2 p2

Ref1 r1 Ref2 r2 Event1 e1

Event2 e2

Event3 e3 Event4 e4

Facettes Puits d'événements

Sources d'événements

Réceptacle

component {

attribute Property1 p1;

attribute Property2 p2;

provides Interface1 i1;

consumes Event1 e1;

consumes Event2 e2;

uses Ref1 r1;

uses multiple Ref2 r2;

emits Event3 e3;

publishes Event4 e4;

} exemple;

component exemple

Jean-Pierre Briot 65 Jean-Pierre Briot DEA SIR -- Conception d’Applications Concurrentes 66

(12)

[Frédéric Peschanski, Middleware 2003]

(13)

MMEvent send(event);

(14)

Scope (F. Peschanski) : Connection Type Inference

• Expressing the dynamics of the type system – adding/removing components and connections

• Automatic type inference of connection between components – connection types used for : data type checks, optimization of connections

• Formalization (state-transition semantics for dynamicity)

• Hierarchical (composite) components

• Type-based multicast (automatic discrimination based on input-types)

Ex : Passive Replication (backup) Protocol Installation (Frédéric Peschanski PhD, Middleware’2003)

Server Requests Replies

Client Client

Server Requests Replies

dynamic and transparent installation of a

«!Passive Replication!»

protocol

«!Passive Replication!»

protocol instance

Server «backup»

«!Replicated!»

role Role assignement

«!Replica!»

role"

(Scope/Comet) prototype formalization (Z + Petri nets) Scheme/Java implementations

http://savannah.nongnu.org/projects/comet

Replication Protocol (2)

role ReplicatedRole { prehook MMRequest ; send MMRequest ; before MMRequest(event) { send (event);

} }

protocol ReplicationProtocol {

public void createReplica(String repClass, Address machine) { ComponentRef ref = upload (repClass, machine);

instantiate (ref);

}

public void doReplication(ComponentRef server, ComponentRef replica) { assign(ReplicatedRole, server);

connect(server, replica, Event);

} } Jean-Pierre Briot DEA SIR -- Conception d’Applications Concurrentes 82

(15)

(16)

(17)

Protocol FlowSyncProtocol {

void sync(ComponentRef server ; ComponentRef client) { assign(client, FlowWatcher) ;

assign(server, FlowRegulator) ; connect(server, client, FlowException) ; } }

(18)

Frameworks

• Squelette d’application

• Ensemble de classes en collaboration

• Framework vs Boîte à outils (Toolkit) – inversion du contrôle

– principe d’Hollywood

application boucle de contrôle

bibliothèque de composants (ex : windows toolkit)

boucle de contrôle

framework Ecrire le corps principal de l’application

et appeler le code à réutiliser

composants de l ’application Réutiliser le corps principal et écrire

le code applicatif qu’il appelle

Frameworks (2)

• Un framework est une généralisation d’un ensemble d’applications

• Un framework est le résultat d’itérations

• Un framework est une unité de réutilisation

• Un framework représente la logique de collaboration d’un ensemble de composants : variables et internes/fixés

• «!If it has not been tested, it does not work!»

Corollaire :

• «!Software that has not been reused is not reusable!»

[Ralph Johnson]

Exemples :

• Model View Controller (MVC) de Smalltalk

• Actalk

Architectures logicielles/Composants vs Frameworks

• Architectures logicielles et composants (et connecteurs) – Générique

– Approches de conception

» descendante

• décomposition

• connexions

» ou ascendante

• assemblage de composants existants

– Les connexions et la coordination («!boucle de contrôle!») restent à définir, puisqu’elle est spécifique à l’application : difficile !

• Frameworks

– Conception initiale du framework ascendante – Mais utilisation (spécialisation du framework) descendante

– Les connexions et la coordination sont déjà définies (et testées) pour une classe d!’applications : plus facile !

Model View Controller (MVC)

Modèle d’interface homme-machine graphique de Smalltalk

Modèle Application

Contrôleur

Affichage

Interaction dépendances

Vue(s)

(19)

Patrons de conception (Design Patterns)

• Idée : identifier les solutions récurrentes à des problèmes de conception

• «!Patterns in solutions come from patterns in problems!»

[Ralph Johnson]

• Analogie :

– principes d’architecture (bâtiments, cathédrales) [Christopher Alexander]

– patrons/archétypes de romans (ex : héros tragique : Macbeth, Hamlet...) – cadences harmoniques : II-V-I, Anatole...

• Des architectes (C. Alexander) aux architectes logiciels – Design Patterns : Elements of Reusable O-O. Software

[E. Gamma, R. Helm, R. Johnson, J. Vlissides (the «!GoF!»), Addison Wesley 1994]

• Les patterns ne font sens qu!’à ceux qui ont déjà rencontré le même problème (Effet «!Ha ha !!»)

– documentation vs génération

Pattern = < Problème , Solution >

• Un pattern n'est pas juste une solution, mais est la discussion d'un type de solution en réponse à un type de problème

• nom (ex : Bridge, Observer, Strategy, Decorator...)

• contexte

• problème

• forces

• collaboration (possible avec d'autres patterns)

• directives

• exemples

• ...

Utilisation :

• Capitalisation de connaissances

• Explication

• Génération (vers une instanciation automatique de patterns)

Ex : pattern Bridge

• Problème : une abstraction peut avoir différentes implémentations

• Solution naïve :

– énumérer/nommer toutes les combinaisons

• MacIconWindow, XIconWindow, etc.

– problèmes :

» combinatoire

» le code du client dépend de l’implémentation

abstraction implémentation

Window

IconWindow LiftWindow

Window

XWindow MacWindow

hérite de (sousclasse de)

Ex : pattern Bridge (2)

• Solution :

– séparer les 2 hiérarchies

IconWindow LiftWindow

Window DrawText() DrawRect()

MacWindow WindowImp DevDrawText() DevDrawRect() imp->DevDrawLine()

...

imp

XWindow DevDrawText() DevDrawRect() DevDrawLine() ...

Ex : pattern Bridge (3)

• Solution générale (le pattern Bridge)

• Exemples d’utilisation : – Multi-fenêtres, libg++, Next AppKit...

• Egalement :

– Langages de patterns (Pattern Languages), ex : GoF book – Patterns d’analyse (Analysis Patterns)

– Patterns seminar group (équipe de Ralph Johnson à UIUC) – Voir : http://www.hillside.net/patterns/patterns.html – Crise actuelle des patterns ?

RefinedAbstraction Abstraction

Operation

Implementor OperationImp() imp->OperationImp()

imp

Implementor OperationImp()

III - Agents

(20)

(sous)-Plan

• Première partie : Introduction aux Agents – Pourquoi les Agents ?

– Positionnement historique (évolution de l'IA et de la Programmation) – Classification (incluant Agents Mobiles et Agents Assistants) – Principes

– Architectures d'Agents

Motivations - pourquoi les agents?

• Complexité croissante des applications informatiques, plus ouvertes, plus hétérogènes, plus dynamiques

– exemple : le Web et toutes les couches et services qui le supportent

– comment décomposer, recomposer, interopérer, gérer l’évolution, adaptation (aux autres modules logiciels, à l’environnement, aux utilisateurs...), contrôle, négocier (partage ressources, prise de RdV),...

– limitations des approches informatiques classiques : statiques, homogènes, interfaces rigides, objets/composants sans initiative propre, client serveur

– difficile à maîtriser par des humains

Exemples

• Contrôle de sonde/vaisseau spatiale – Distance avec le contrôle au sol -> temps de réaction – -> Nécessité d!’un contrôle local : autonomie

– capacités de prises de décision en cas de situations non prévues : initiative

• Recherche d’information sur Internet

– Processus long et difficilement prédictible (attente, découverte, pannes…) – -> Délégation du cahier des charges : guidé par les objectifs – ex : recherche multilingue - coopération de différents agents

» (personnalisation, ontologie, dérivations, traduction, etc.) [Projet SAFIR]

• Prise de RdV

– fastidieux, attentes (indisponibilité ou déconnexions)

– -> PDAs assistants (apprend habitudes utilisateur et initiative) et coopératifs

• etc, ex : Surveillance de réseaux – détection, intervention, réparation

Idées

• Agents logiciels – autonomie – mission – initiative – niveau connaissance – adaptation – inter-opérabilité

– De plus, ils peuvent être coopératifs (avec autres agents)

• ex : prise de RdV distribuée

– On parle alors de :

• Systèmes multi-agents

(issus du domaine «!résolution distribuée de problèmes!») – protocoles de communication

– protocoles de coordination – organisations

Qu’est-ce qu’un agent ?

• Petit Robert : – De agere «!agir, faire!»

• «!Celui qui agit (opposé au patient qui subit l’action)!»

• «!Ce qui agit, opère (force, corps, substance intervenant dans la production de certains phénomènes)!»

– De agens «!celui qui fait, qui s!’occupe de!»

• «!Personne chargée des affaires et des intérêts d’un individu, groupe ou pays, pour le compte desquels elle agit!»

• «!Appellation de très nombreux employés de services publics ou d’entreprises privées, généralement appelés à servir d’intermédiaires entre la direction et les usagers!»

• American Heritage Dictionary :

– «!one that acts or has the power or authority to act... or represent another!»

– «!the means by which something is done or caused; instrument!»

Qu’est-ce qu’un agent ? (2)

• [Ferber 95]

– on appelle agent une entité physique ou virtuelle

• qui est capable d’agir dans un environnement,

• qui peut communiquer directement avec d’autres agents,

• qui est mue par un ensemble de tendances (sous la forme d’objectifs individuels ou d’une fonction de satisfaction, voire de survie, qu’elle cherche à optimiser),

• qui possède des ressources propres,

• qui est capable de percevoir (mais de manière limitée) son environnement,

• qui ne dispose que d’une représentation partielle de cet environnement (et éventuellement aucune),

• qui possède des compétences et offre des services,

• qui peut éventuellement se reproduire,

• dont le comportement tend à satisfaire ses objectifs, en tenant compte des ressources et des compétences dont elle dispose, et en fonction de sa perception, de ses représentations et des communications qu’elle reçoit.

(21)

Rappel historique (vis à vis de l’IA)

• Concept d’agent rationnel à la base de l’intelligence artificielle (IA) – système informatique autonome

• connaissances, buts, pouvoirs, perceptions, raisonnement/délibération (résolution, planification, déduction, etc.), actions

• système expert

• Limitation : Autarcie !!

– autarcie logicielle : difficile à faire collaborer avec d’autres logiciels

– autarcie sociale : censé remplacer l’homme, pas de collaboration (expert humain en dehors de la «!boucle!»)

• Réponses – agents coopératifs

• systèmes multi-agents

• issus de la résolution distribuée de problèmes – distributed artificial intelligence (DAI versus GOFAI) – agents assistants

Rappel historique (vis à vis de la programmation)

• Interview Les Gasser, IEEE Concurrency 6(4):74-81, oct-déc 98

• langage machine

• assembleur

• programmation structurée

• programmation par objets

• programmation par agents !

• concept d’action persistante

• programme qui tente de manière répétée (persistante) d’accomplir quelque chose

• mission et initiatives pour l’accomplir

action persistante

• programme qui tente de manière répétée (persistante) d’accomplir quelque chose

– pas la peine de contrôler explicitement succès, échec, répétition, alternatives...

• description de : – (quand) but == succès – méthodes alternatives

– * apprentissage (de nouvelles méthodes)

• ressources : – processus – itération (tant que)

– options/solutions (situation -> action) – capacité de choix (on line - sélection d’action) – recherche (search) -- en cas de nouvelles situations – feedback sur le choix

Une vision différente du logiciel (vers un couplage sémantique et adaptatif)

• Problème clé du logiciel : évolution, adaptation

– profil utilisateur, programmeur, environnement, contraintes - ex : QoS, ...

– Pour un système (logiciel) complexe, impossible de prédire au moment de la conception toutes les interactions potentielles

– Ceci est rendu encore plus difficile si l’on considère l’évolutivité du logiciel ainsi que celle de son environnement (autres logiciels)

• Vers des composants logiciels «!adaptables!»

– Les interactions non prévues deviennent la norme et non plus l’exception [Jennings 1999]

– Le couplage entre composants est abordé au niveau des connaissances et non plus au niveau des types de données (ce qui est sûr mais rigide)

– Vers un plus grand découplage : objets -> composants -> agents (et ensuite ?!)

– A rapprocher du "Ever late binding" (C -> C++ -> Java -> ...)

typologie (Babel agents) 1/3

• agents rationnels

– IA, comportement délibératif, perceptions, croyances, buts – ex : systèmes experts

• systèmes multi-agents

– résolution distribuée (décentralisée) de problèmes – coordination, organisation

– ex : robotique collective

• agents logiciels

– ex : démons Unix, virus informatiques, robots Web

• agents mobiles

– code mobile -> objet mobile -> agent mobile (processus)

– motivations : minimisation communications distantes, informatique nomade – technologie en avance sur les besoins

– problèmes de sécurité, coquilles vides

typologie (Babel agents) 2/3

• agents assistants

– secrétaire virtuelle (trie le mail, gère les RdVs...) – < logiciel utilisateur + assistant >

– filtrage collaboratif

• ex : recommandation achats CDs par recherche de similarité des profils puis transitivité – computer-supported cooperative work -> communityware (pour citoyens) – agents «!émotionnels!»

• agents robotiques – architectures de contrôle de robots – sélection de l’action

– robotique collective (ex : RoboCup, déminage...)

• vie artificielle – alternative à l’IA classique

– modélisation/simulation des propriétés fondamentales de la vie (adaptation, reproduction, auto-organisation...)

– importation de métaphores biologiques, éthologiques...

– ex : algorithmes à base de fourmis (agents) pour routage de réseaux

(22)

typologie (Babel agents) 3/3

• simulation multi-agent

– simulation centrée individu vs modèle global (ex : équations différentielles) – modèles de comportement arbitrairement complexes

– interactions arbitrairement complexes (ex : sociales : irrigation parcelles) – niveaux hiérarchiques (ex : bancs de poissons)

– espaces et échelles de temps hétérogènes – couplage de processus

• agents de loisir – virtuels (ex : jeux vidéo) – virtuels-physiques (ex : Tamagotchi) – physiques (ex : Furby, robot-chien Aibo de Sony)

• agents artistiques – art interactif – éco-système – créatures virtuelles

Agents robotiques

• jouet

• équipe (RoboCup)

• aspirateur

• tondeuse-à-gazon

• démineur

• ...

Code/objets/agents mobiles

• Code mobile

– rapprocher (code) traitement des données – ex : SQL

client base de

données code de

sélection

résultat

• Objet mobile

– PostScript (code + données constantes) – Emerald [Black et al. IEEE TSE 87]

A

C

B

• call-by-reference

• call-by-value

• call-by-move/visit

C’

Agents mobiles

• A la différence du code ou de l’objet mobile, c’est l’agent mobile qui a l’initiative de son déplacement

• Langages : – Telescript (initiateur)

– (Java-based) Odissey, Aglets, Voyager, Grasshopper, D’Agents (ex-AgentTcl), etc.

– Standardisation :

• OMG MASIF

• FIPA

agent mobile

place1

place2

place3

Agents mobiles (2)

• Avantages des (mis en avant par) les agents mobiles – Réduction du trafic (traitement local -> données échangées réduites)

• agents mobiles vs RPC – Robustesse

• Déconnexion du client mobile (informatique nomade : pause, tunnel, ombre…) – Confidentialité (traitement local)

• (mais problèmes de sécurité) – Evolution logicielle

• Off-line

– Diffusion (versions) de logiciels (download)

• On-line – Réseaux actifs

• Données et Méta-données de contrôle (capsules)

• «!Find the killer application !!»

• Une nouvelle technique (parmi les) de programmation répartie

• Combinaison (avec les autres : RPC, réplication, etc.) et non pas remplacement

• Recherches actuelles

• Sécurité

• Hétérogénéité

• Collaboration (les agents mobiles actuels restent encore trop souvent solitaires)

Agents assistants

• Limitations des interfaces homme-machine classiques – à manipulation directe / explicite

– rigidité, complexité, ne s’améliore pas à l’usage

• Agents assistants

• adaptation au profil de l’utilisateur, automatisation de certaines tâches, rappel d’informations utiles, initiative

• ex : trieur de mails, prise de RdVs