Projet KLEE

1
Projet KLEE

• Langages à objets, programmation par aspects et
  modèles de composants vers des architectures
  logicielles adaptables
• Pierre Cointe
• cointe_at_emn.fr

2
Composition de KLEE

• Pierre Cointe (Pr, resp scientifique)
• Jacques Noyé (MC, resp permanent)
• Rémi Douence (MC)
• Thomas Ledoux (MC)
• Gilles Muller (Pr)
• Jean-Marc Menaud (MC)
• Mario Südholt (MC)
• plus 7 doctorants

3
Le contexte

• Avec la montée en puissance des réseaux et du
  réseau des réseaux, les métiers sont en droit de
  réclamer
• la mise à disposition de composants logiciels sur
  étagères
• prenant en compte les évolutions des standards
  industriels de facto et leur pluralité
• ne faisant apparaître que les aspects métiers
• disposant doutils de gestion intégrés
• le passage à l échelle de leurs applications
• dans lespace en terme de taille
• dans le temps en terme de cycle de vie
• avec des assurances en terme de ltlt qualité de
  service gtgt
• Ces deux points constituent lenjeu des
• architectures logicielles d ltlt entreprise gtgt

4
Parmi les domaines concernés

• Architectures logicielles métiers
• Informatique de gestion
• Commerce électronique
• Enseignement à distance
• Systèmes, réseaux et télécommunications
• Systèmes dinformation mobiles
• Intergiciels
• Noyaux des systèmes

5
Pourquoi le nom Klee?

• Mais lindustrialisation du logiciel,
  cest-à-dire ladaptation de ses composants à
  leur usage, induit des tensions fortes entre
• structure et ouverture
• standardisation et personnalisation
• pouvoir dexpression des formalismes existants et
  complexité inhérente aux architectures
  logicielles

6
Notre approche langage

•  Proposer des "outils" de construction
  darchitectures logicielles à base de composants
  avec pour objectif dobtenir une adaptabilité
  satisfaisante en (ré-)utilisant les techniques
  issues des langages de programmation et en
  particulier des langages à objets et à aspects 

Réflexion, Spécialisation Analyse de programme
7
Les verrous Limites des langages à objets

• Supportent mal le passage à l échelle
• Autant de modèles à objets que de langages
• Pas de neutralité vis-à-vis du langage
  dimplémentation
• Besoins de structuration (packages, modules, ...)
• Lhéritage n est pas LA solution à tous les
  problèmes de réutilisabilité
• Manque de modularité et faiblesse de
  lencapsulation
• Anomalie dhéritage (concurrence, instanciation,
  )
• Problème de réification des propriétés
  transverses à un ensemble d objets
• Difficilement extensibles pour prendre en compte
  de nouvelles dimensions (sécurité, mobilité, )
• Java C ne constituent pas la solution ultime

8
La modularité des aspects traverse celle des
classes (G. Kiczales)
Display

FigureElement
Figure
Point
Line
2
getX() getY() setX(int)setY(int)
getP1() getP2() setP1(Point)setP2(Point)
MoveTracking
9
Interface FigureElement
Expression Java dun déplacement

• class Point implements FigureElement
• private int _x, _y
• public Point(int x, int y)
• _xx _yy
• public int getX() return _x
• public int getY() return _y
• public void setX(int x) _xx
• public void setX(int y) _yy

• class Line implements FigureElement
• private int _p1, _p2
• public Line(Point p1, Point p2)
• _p1p1 _p2p2
• public Point getP1() return p1
• public Point getP2() return p2
• public void setP1(Point p1) _p1p1
• public void setP2(int p2) _p2p2
• pointcut moves()

10
Expression AspectJ dun déplacement(merci Gregor
!)

• aspect MoveTracking
• static boolean flag false // bit saying
  that some figure elt has moved
• static boolean testAndClear()
• boolean result flag
• flagfalse
• return result
• pointcut moves()
• receptions(void Line.setP1(Point))
• receptions(void Line.setP2(Point))
• receptions(void Point.setX(int))
• receptions(void Point.setY(int))
• static after() moves ()
• flag true

11
Les verrous Immaturité et diversité des modèles
de composants (industriels)

• Les standards industriels de facto brillent par
  leur absence de formalisme, ils sont complexes à
  comprendre et à utiliser, difficiles à étendre et
  à généraliser.
• Lindépendance par rapport aux langages et aux
  infrastructures n est pas garantie
• Ne proposent pas d intermédiaire entre
  assemblage type  boîte blanche 
  (source/développement) et assemblage type  
  boîte noire  (binaire/déploiement)
• Les langages dinterfaces, pour assurer
  linteropérabilité et la validation des
  assemblages, ne permettent pas de décrire la
  sémantique des interactions
• Les descripteurs ne gèrent que des services
  techniques prédéfinis (pb ajout de nouveaux
  services techniques et métier)

12
Traits essentiel dun composant

• Encapsulation spatiale (gt objet)
• boîte noire/noyau emballage/enveloppe
• Encapsulation temporelle
• développement à étapes
• fabricant du composant ? utilisateur du composant
• Assemblage connexion et adaptation
• les lego ou les composants électroniques sont de
  mauvaises métaphores
• utilisation de l'auto-description du composant
  (mode d'emploi dans l'emballage)

13
Un constat émergence des aspects

• Décoration des langages de programmation
• Exceptions/concurrence/persistance/...
• Le pattern MVC (Model/View/Controller)
• Concevoir en toute indépendance le modèle
• Ajouter ensuite les vues et les contrôleurs pour
  lIHM
• Connecter manuellement les éléments de la
  trilogie par un système de dépendances
• Architectures à méta-niveaux
• Séparation du pourquoi/comment
• Les services des intergiciels
• Livrés en nombre prédéfinis mais non composables
• Aspiration à ouvrir les conteneurs pour faciliter
  l association services techniques et composants
  métiers.

14
La CVM (Machine Virtuelle Composant)

• Un cadre pour la formalisation et la mise en
  uvre de langages d aspects et de composants
  incluant les outils de la réflexion et de la
  spécialisation pour traiter ladaptabilité.
• À l intersection des quatre thèmes suivants
• Évolution des langages à objets
• Les langages daspects
• Les langages à composants
• L'adaptabilité

15
CVM Évolution des objets

• Prolongement des expériences des MOP Java
• RAM mobilité forte à partir de la JVM par
  réification de la pile d exécution
• Reflex canevas pour la définition de MOP Java
• Construction dun Java réflexif pour lexécution
  dapplications à base de composants dans des
   conteneurs ouverts 
• Réification des aspects dans un langage à classes
  
• Composition des aspects
• Aspects versus héritage
• Intégration des résultats dans lIDE Eclipse

16
CVM Les langages d'aspects

• Caractérisation et représentation des aspects à
  l aide d événements traités par des moniteurs
  dexécution
• Étude du tissage des aspects sémantique du
  programme tissé, composition des aspects,
  interaction des aspects, réutilisabilité des
  aspects
• Prise en compte du coût (temps/mémoire) des
  aspects
• Définition dun langage à composants intégrant
  une notion d aspects permettant de décrire la
  communication, la sécurité, lintrospection, ...

17
CVM Les langages à composants

• La structure des composants, leur cycle de vie et
  leurs interactions devront être explicitement
  représentés et adaptés
• Définition d un support réflexif pour réaliser
  cette représentation (introspection) et cette
  adaptation (intercession)
• Utilisation des aspects pour exprimer les
  dépendances trans-composants
• Interfaçage avec les standards CCM, .net et EJB

18
CVM de ladaptabilité

• Adaptabilité fermée (par spécialisation) /
  ouverte (introduction de mécanismes et de
  politiques d'adaptation)
• Adaptabilité statique/dynamique
• Adaptabilité et cycle de vie (prise en compte du
  développement à étapes)
• Impact du changement au niveau composant, aspect,
  application (adaptabilité au vol de
  l'architecture globale)

19
Interactions avec dautres projets INRIA

• Thème 2A
• Lande à Rennes (T. Jensen)
• Cristal à Rocquencourt (M. Mauny)
• Compose à Bordeaux (C. Consel)
• Miró à Nancy (L. Liquori D. Colnet)
• Oasis à Sophia (I. Attali)

• Autres thèmes
• Triskell à Rennes (J-M. Jézéquel)
• CoLo à Lille (J-M. Geib)
• Sardes à Grenoble (J-B. Stéfani)

20
Collaborations internationales

• G. Kiczales à Xerox Parc à l'université de
  British Columbia
• J. Palsberg et J. Vitek à Purdue
• M. Aksit à l'université de Twente
• K. Lieberherr à Northeastern University
• M. Mezini à la Technical University of Darmstadt
• S. Matsuoka et S. Chiba au Tokyo Institute of
  Technology
• G. Blair à l'université de Lancaster
• O. Nierstrasz à l'université de Berne

21
Programmation par aspectset avant-projet KLEE

• Pierre Cointe Mario Südholt

22
Problèmes des approches actuels

• Traitement déclaratif daspects complexes
• Séparation insuffisante entre le langage de
  coupes transverses et le langages dactions
• Définition sémantique
• Imprécise voire empirique dans les cas d AspectJ
• Difficulté à exprimer les structures à
  multi-niveaux (visibilité inter-aspects)
• Comment garantir la préservation des propriétés
  du code source au programme tissé ?

23
Notre modèle pour AOP les aspects
événementiels

• Utilisation de moniteurs pour contrôler
  lexécution du programme de base
• Points de jointure événements émis
• Coupes transverses motifs de séquences
  dévénements
• Tisseur
• Reconnaissance de motifs occurrence dune coupe
• Exécution dune action

24
Un exemple du commerce électronique

• Facturer un produit à un client en fonction de
  commandes préalables
• Aspects événementiels une coupe !

transaction actuelle
rabais
rabais
client
produit
commande
commande
choix
auth.
facturation
25
Langage spécialisé de coupes

• Data Pattern // coupes séquentielles
  Return Crosscut Bind(Crosscut -gt
  Pattern) Pattern Seq Pattern
  // filtres Filter (Event -gt
  Bool) // coupes parallèles
  Pattern Par Pattern First Pattern
  

26
Cadre formel

• Formalisation sémantique fonctionnelle
• Langage dédié pour exprimer les coupes
• Formulation concise de coupes complexes
• Preuves des propriétés daspects et du tissage
  Douence, Motelet, Südholt Reflection01
• Restriction sur expressions régulières
• Analyse statique dinteractions et résolution de
  conflitsDouence, Fradet, Südholt GC02 soumis

27
Travaux actuels systèmes/langages

• AspectJ (Xerox)
• Coupes ensembles de points dexécution (pas de
  relation entre ces points except. cflow)
• Actions Java
• Tisseur transformation de programme
• HyperJ (IBM)
• Coupes sur la structure dune application
  (héritage, paquetage) et leur réorganisation
• JAC (Lip6)
• Pas de langage de coupes spécialisé systèmes
  réflexifs

28
Travaux actuels formalisation

• Aspects événementiels (EMN)
• Langage expressif de coupes
• Wand et al., FOOL02
• Sémantique monadique
• Formalisation daspects type AspectJ, AOP
  sandbox
• Lämmel, PEPM99
• Manipulation de grammaires