BOM - Bilan

1
BOM - Bilan

• ClearSy,
• Gemplus,
• LIFC,
• LSR-IMAG

2
Plan

• Objectifs du projet BOM
• Evolution du langage B0
• Le cas détude
• Les traducteurs
• Métriques
• Conclusions

3
Objectifs

• Permettre lutilisation de la méthode B pour le
  développement de logiciels carte à puce et
  embarqués avec garantie absolue
• Développement dun traducteur répondant aux
  contraintes de la carte
• Promouvoir lutilisation de B
• Principaux résultats mis à la disposition de la
  communauté sous licence  Open Source 

4
BOM et la Java Card
API (Java)
Applet 1
C
VM (C)
Applet 2
Java
OS (C)
Applets (Java)
5
La méthode B

• Méthode Formelle destinée au développement de
  logiciels prouvés et corrects par construction
• Basée sur de solides fondations mathématiques
• Adaptée au développement carte à puce
• Formalisme pour les spécifications amont
• Langage dimplémentation proche des langages de
  développement
• Distinction claire entre spécification et
  implémentation
• Remplacement des tests par une phase de preuve
• Méthode déjà utilisée industriellement

6
Développement classique
7
Développement B
8
Problèmes visés par le projet

• La génération de code automatique nest pas
  adaptée aux contraintes de la carte à puce
• Code généré pas assez compact
• Trop consommateur en ressources
• Pas de génération de code pour les plates-formes
  récentes
• Java / .NET (C)
• Empêche lutilisation de B pour la génération de
  code carte à puce embarqué

9
BOM

• Projet RNTL
• Démarrage août 2000, fin mars 2003
• Partenaires
• ClearSy
• Commercialise lAtelier B
• Gemplus
• Utilise la méthode B
• LIFC (Laboratoire dInformatique de
  Franche-Comté)
• Développe une plate-forme expérimentale et
  pédagogique autour de B
• LSR-IMAG
• Réalise des travaux théoriques et des outils
  expérimentaux sur B

10
Décomposition
11
Principaux résultats

• Évolution du langage dimplémentation B0
• Plus adapté à la génération de code efficace
• Cas détude
• Implémentation en B dun sous-ensemble de Java
  Card
• Traducteurs
• Traducteur B vers C
• Traducteur B vers Java / C

12
Plan

• Objectifs du projet BOM
• Evolution du langage B0
• Le cas détude
• Les traducteurs
• Métriques
• Conclusions

13
Evolution du langage B0 (1)

• Pouvoir dexpression accru
• Permet lutilisation de types spécialisés
• Autorise le passage de tableaux par référence
• Permet de guider les optimisations
• Extensible
• Permet dajouter des types et des opérateurs

14
Evolution du langage B0 (2)

• Plus simple à analyser et à traduire
• Permet une traduction fiable
• Plus restreint pour plus defficacité
• Simplifie la compréhension et la relecture

15
Plan

• Objectifs du projet BOM
• Evolution du langage B0
• Le cas détude
• Les traducteurs
• Métriques
• Conclusions

16
Cas détude (1)

• Développement B d'une machine virtuelle
• Permet dassurer quune applet vérifiée
  nentraînera pas derreur à lexécution
• Développement  prouvable  
• Preuves effectuées par échantillonnage
• Architecture et modélisation permettant
  d'effectuer ces preuves si nécessaire
• Sous-ensemble de la VM Java Card
• Ne traite pas les interfaces et les tableaux
• Capable dexécuter de petites applets spécifiées
  et prouvées en B
• Utilisation du traducteur Java

17
Cas détude (2)

• Résultat dune collaboration entre tous les
  partenaires
• Support de ClearSy pour larchitecture et la
  preuve
• Modélisation du JCRE et dune applet par le LIFC
• Traitement de la gestion des objets par le LSR
• Développement de linterpréteur et intégration
  par Gemplus
• Fertilisation croisée des savoir-modéliser des
  partenaires

18
Plan

• Objectifs du projet BOM
• Evolution du langage B0
• Le cas détude
• Les traducteurs
• Métriques
• Conclusions

19
Traducteurs

• Traducteurs vers C et Java
• Réalisés par ClearSy et le LIFC
• Versions générales Open Source
• Java pour la partie applicative
• C pour la partie système
• Version C pour carte à puce propriété Gemplus

20
Traducteurs

• Offrent une correspondance simple entre le B
  écrit et le code généré
• Pas des traducteurs  optimisants , mais des
  traducteurs permettant décrire des
  implémentations efficaces
• Algorithmes utilisés validés par études théoriques

21
Traducteur Java

• Schéma général de traduction
• Une classe par machine B
• Optimisé pour le cas où une seule instance de
  machine est utilisée pas dinstanciation
  dobjets
• Délégation aux mécanismes du langage objet des
  points B complexes
• Espace de nommage
• Multiples instances
• Optimisations laissées à limplémentation du
  langage objet (Valuation des constantes)

22
Traducteur Java

• Utilisable pour Java Card
• Restriction du Java généré au sous-ensemble Java
  Card (type dentier utilisé)
• Extensible à dautres langages à objets
• Étendu vers C (1 h.m de charge de travail)
• Testé sur un ensemble de petits projets et sur
  lexemple classique du DAB
• Intégré dans une plate-forme ouverte (GNU GPL)
  dutilisation de B

23
Traducteur C (1)

• Tire parti des améliorations du B0 pour optimiser
  lutilisation de la mémoire
• Traitement des points complexes directement par
  le traducteur
• Espace de nommage
• Restriction sur le multi-instance
• Traducteur modulaire

24
Traducteur C (2)

• Utilisation de règles de traduction pour la
  génération de code
• Adaptation à un compilateur cible
• Réalisation doptimisations locales
• Permet à lutilisateur dinfluer sur le code
  généré
• Par la modification du source B
• Par lécriture de règles de traduction
  spécifiques
• Extensible à dautres langages procéduraux

25
Traducteur C Carte à puce

• Utilise un jeu de règles spécialisées
• Ajoute un expanseur de code en ligne (Inliner)
• Laisse le contrôle de loutil à lutilisateur
• Supprime le code non utilisé

26
Validations théoriques sur Traducteurs

• Apportent une garantie sur les points complexes
  traités par les traducteurs
• pas de risque de conflits grâce au renommage des
  identificateurs
• règles utilisées par le traducteur pour
  lexpansion en ligne
• passage de tableaux par référence

27
Plan

• Objectifs du projet BOM
• Evolution du langage B0
• Le cas détude
• Les traducteurs
• Métriques
• Conclusions

28
Métriques

• Comparaison effectuée sur le cas détude
• Différentes plates-formes  carte 
• Comparaisons
• Taille de code généré
• Utilisation RAM
• Comparaison par rapport à une implémentation
  manuelle

29
Taille de code généré
30
Comparaison mémoire

• Sur cas détude
• 4 variables 8 bits, 10 variables 16 bits, 109
  liens entre machines

31
Comparatif par rapport à du code écrit
manuellement
AVR
SmartMIPS
32
Apport des différents composants
33
Plan

• Objectifs du projet BOM
• Evolution du langage B0
• Le cas détude
• Les traducteurs
• Métriques
• Conclusions

34
Valeur ajoutée de la coopération

• Mise en commun des idées et points de vue
  théoriques
• Levée de difficultés de Gemplus sur la
  modélisation B
• Échanges sur la définition du B0
• Partage des savoir-faire
• Développement doutils
• Compétences carte à puce
• Langages

35
Conclusions

• Traduction vers C
• Améliorations drastiques par rapport à lAtelier
  B
• Surcoût réduit par rapport à implémentation
  manuelle
• Permet dembarquer du code C prouvé
• Utilisable dans lAtelier B
• Traduction vers Java / Java Card
• Ouvre la voie à la génération de code pour les
  nouvelles plates-formes logicielles (Java, .NET)
• Cas détude
• Pourrait être étendu à un développement formel
  réel ou un modèle pour certification

36
Exploitation des résultats

• Mise a disposition du cas détude et des
  traducteurs sous licences  Open Source 
• http//lifc.univ-fcomte.fr/tatibouet/WEBBOM
• Méthode B utilisable dans le domaine des cartes à
  puce
• Extension à dautres domaines embarqués