MASTER ACADEMIQUE

N° d‟ordre :
N° de série :
République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Superieur et de la Recherche
Scientifique
UNIVERSITÉ D’EL-OUED HAMA MAKHDHER
FACULTÉ DES SCIENCES ET DE TECHNOLOGIE
Mémoire de fin d’étude
MASTER ACADEMIQUE
Domaine: Mathématiques et Informatique
Filière: Informatique
Spécialité: Systèmes Distribués et Intelligence Artificielle
Présenté par:
Melle KEDADRA Roua
Melle REZZAG BARA Intissar
Thème
Les approches formelles pour
les applications JAVA
Soutenu le 04 juin 2015
Sous la supervision de : Mr. Meftah Mohammed Charaf Eddine
Année universitaire 2014 – 2015
Remerciements
Avant tous, je remercie Allah le tout puissant de m’avoir donné le
courage et la patience pour réaliser ce travail malgré toutes les
difficultés rencontrées.
J’adresse mes vifs remerciements à mon encadreur Mr.Charaf aldine
MEFTAH pour son effort et ses conseils
Mes remerciements s’adressent aussi à tous les enseignants et les
professeurs qui ont contribué à ma formation et à tous ceux qui m’ont
aidé pendant la réalisation de ce travail.
Aussi à mes collègues de la promotion 2014-2015
Master Informatique
Je remercie également tous ceux qui ont participé de près
Ou de loin à élaborer ce travail.
Enfin, je remercie les membres du jury qui ont bien accepté de juger et
d´évaluer ce travail.
2
Dédicaces
Je remercie tout d’abord notre dieu tout puissant
J’ai tant rêve du jour ou je pourrais réaliser une de mes ambitions et
celle de mes très chers parent, à cette occasion j’en profite pour dédier
mon travail avec un très grand plaisir :
A l'âme de mon grand-père cher,je t'aime je te souhaité le paradis et la
miséricordede Dieu Tout-Puissant.
A ma grand-mère , Dieu protège et vous guérir, et la longueur de votre
âgemameilleur grand-mère.
A ma mère, Est la plus belle et la meilleure et la mère de nostalgie sur la
terre je vous remercie de veiller pour moi et tous les sacrifices que je le
dis: Je t'aime tellement, ma chère mère et cher vous êtes vraiment
merveilleuxje vous souhaite la santé et la longévité et bonheur.
A mon père, Merci, cher père sur tout ce que vous loin, mais sera
toujours près de moi, je vous souhaite la santé et la longévité.
A mon seul oncle, Abd.Alrazak Merci à vous et je vous souhaite la santé.
A mes tante,Fatiha, Salima, Karima, Saida, kaltoum, Meriem.
A mes oncles, P.Mohamed , Hachani , khazani , Nouri , Lmouldi ,
Mohamed
Et Tous leurs maris, leurs enfants, et leurs filles chacun de son nom.
A mes fréres et mes soeurs, spécialement Tamadheret son mari
Mohamed, YoucraKhadija, Mohamed,Tasnimet surtout les bébé : Nouhet
Abd.Alkader
Et : Bachir et son marie Hanan et ton bébé Moudi, Asma, brahim et son
mari Rima, Sara,Oussama, Chaima, Chaima, Manelet son mari Ahmed et
tes filles :
Riham , Rinad , Ritan.
Et Bachir , Oussama , Abir , Samah, Youcra, Amani.
A mon fiancé, Yahia et tout les familles.
A mon binome , Wouroud qui a fournit des efforts immeenses.
A mes cher Amis,Wouroud ,Safa ,Iintissar , Nadjah, Insaf , Imane ,
Intissar.K.
j'aime très beaucoupW.ROSANA.I4.
A toute la promotion informatique 2013.
3
J’en suis vraiment reconnaissante.
Roua
Dédicaces
Avant tous, je remercie dieu le tout puissant de m’avoir donné le courage et la
patience pour réaliser ce travail malgré toutes les difficultés rencontrées.
Je dédie notre ouvrage à :
Ma très chers parents adorés qui m‘ont fait bénéficier, grâce à leur invocation et
à leur bénédiction, à avoir la confiance et l'espoir au cours de la rédaction de ce
travail.
Je le dédie aussi
A mes souers: Soumaia, Meriem, Haifa, Malak.
A mes frères : Yacine, Haitham, Med Iyade.
A mon grand-père, mes tantes et leurs enfants. A mes oncles et leurs enfants
Et à toute la famille.
A mon binome Roua.
A mes meilleurs amis : najah, intissar, amira, insaf, safa, wouroud,
imane.
A tous les étudiants de la faculté Informatique surtout les étudiants
de la 2ième année master promotion 2015
Intissar
4
Résumé
Le langage java est une technologie récente et un domaine de recherche très actif,
en particulier par sa capacité étonnante de modélisation des différents types de
systèmes. Cependant, le potentiel des systèmes Multi-Agent ne devrait pas cacher les
difficultés liées à la conception et la vérification des systèmes Multi-Agents qui
peuvent causer la crédibilité scientifique de ce domaine.
Dans le but de pallier ce type de problème, il devient donc crucial d'avoir des
méthodes rigoureuses de spécifications et de vérification formelles pour assurer le
développement sûr des systèmes Multi-Agents.
Notre projet de recherche s'inscrit dans ce contexte et nous tentons de vérifier un
ensemble de propriétés pertinentes des systèmes Multi-Agents, en se basant sur
l‟utilisation de la logique de réécriture et la technique de vérification formelle
Mots clés : langage java, méthode formelle, méthode B, java swing, la
validation, atelier B, la logique, machine abstraite.
5
Abstract
Java is one of the modern technology and an active area of research, particularly
through the amazing ability to model different types of system. However, the
possibilities owned by the Java language that does not hide the difficulties relating to
the design and verification of these systems that can cause the scientific credibility of
this area, and from here we consider the formal approach is to treat the complexities
of programs, through verification of software and available applications.
In order to overcome these difficulties, it is important to have strict formal
methods of verification and specifications to ensure the safe development of the use
of the B method.
In this context, our research falls in the attempt to convert a specific application
and is limited to the language of Java to B method and to ensure the investigation and
a set of properties for this application through specific conditions with respect to the
arrangement of the modeled well free of errors.
Our research falls in the attempt of proposing a formal approach for java
application.
Keywords: java language, formal method, B Method, validation, abstract machine.
6
‫ملخص‬
‫لغةةةةةح جافةةةةةا تعتثةةةةة هةةةةةي التكٌْلْجيةةةةةا الحديثةةةةةح ّهٌطقةةةةةح ًشةةةةةطح فةةةةةل ه ةةةةةا‬
‫خةةةة‬
‫القةةةةد ج الوذُلةةةةةح لٌوذجةةةةح أًةةةةةْا هختلفةةةةح هةةةةةي الٌظةةةةام‪ّ .‬هةةةةك ‪,‬لةةةةة‬
‫الثحةةةةةْ‬
‫ّال سةةةةةيوا هةةةةةي‬
‫فةةةة ى إهكاًيةةةةةاخ التةةةةل تولكِةةةةةا‬
‫لغةةةةةح جافةةةةةا ال تخفةةةةةل الصةةةةةةعْتاخ الوتعلقةةةةةح تالتصةةةةةوين ّالتحقةةةةة هةةةةةةي ُةةةةةذٍ االًظوةةةةةح التةةةةةل يوكةةةةةةي أى‬
‫تسةةةةةثة الوْثْقيةةةةةح العلويةةةةةح لِةةةةةذا الو ةةةةةا ‪ ّ ,‬هةةةةةي ٌُةةةةةا ا تث ًةةةةةا الةةةةةٌِس ال سةةةةةول ُةةةةةْ لعةةةةة‬
‫الث اهس هي خ‬
‫تعقيةةةةةداخ‬
‫التحق هي الث ه ياخ ّالتطثيقاخ الوتاحح‪.‬‬
‫هةةةةةةةي أجةةةةةةة التغلةةةةةةةة لةةةةةةة ُةةةةةةةذٍ الوشةةةةةةةكلح يصةةةةةةةث هةةةةةةةي األُويةةةةةةةح أى تكةةةةةةةْى أسةةةةةةةالية صةةةةةةةا هح‬
‫ّهْاصفاخ سويح للتحق ّ لضواى التٌويح اآلهٌح تاستعوا الط يقح ‪-‬ب‪-‬‬
‫فةةةةل ُةةةةذا السةةةةياا يٌةةةةد‬
‫تحثٌةةةةا فةةةةل هحاّلةةةةح تحْيةةةة تطثيةةةة هعةةةةيي ّ هحةةةةدّي هةةةةي لغةةةةح جافةةةةا الةةةةل‬
‫ط يقةةةةةةح ‪ -‬ب‪ ّ -‬التأكةةةةةةد ّ التحقيةةةةةة هةةةةةةي ه وْ ةةةةةةح الخصةةةةةةا‬
‫هحديج هك احت ام الت تية لوذجتَ تشك جيد خا هي األخطاء‪.‬‬
‫الكلمات المفتاحية‪ :‬الط يقح ال سويح الط يقح ‪ -‬ب‪ -‬التحق هي صحح‪.‬‬
‫‪7‬‬
‫لِةةةةةةذا التطثيةةةةةة هةةةةةةي خةةةةةة‬
‫ةةةةةة ّط‬
Sommaire
Glossaire ................................................................................................................. 10
01
Listes des figures et des tables ..............................................................................11
00
Introduction ............................................................ Error! Bookmark not defined.
1.Contexte général et Problématique...................... ................................................. 13
2.Objectifs............. ................................................................................................... 14
3. L'organisation du mémoire……………………………………………………...
.................................................................................. Error! Bookmark not defined.
Chapitre I:
La Langage JAVA
I.Introduction ……………………………………..………………………………...16
II.La Logique Réécriture.... ...............................................Error! Bookmark not defined.
II.1. Théorie de réécriture ......................................................................................... 16
II.2. Les systèmes de réécriture conditionnels ......................................................... 17
II.3. Règles de Déduction ........................................ Error! Bookmark not defined.
II.4. Réécriture concurrente ...................................... Error! Bookmark not defined.
II.5. Langages Basés sur la Logique de Réécriture .................................................. 19
III.Système Maude .... .........................................................Error! Bookmark not defined.
III.1. Les caractéristiques du Maude ....................... Error! Bookmark not defined.
III.2. Différents Modules de MAUDE ..................... Error! Bookmark not defined.
III.2.1.Modules Fonctionnels................................ Error! Bookmark not defined.
III.2.2.Modules systèmes ...................................... Error! Bookmark not defined.
III.2.3.Modules orientés objet............................... Error! Bookmark not defined.
IV.Exécution et Analyse formelle sous Maude.... .........Error! Bookmark not defined.
IV.1. Analyse formelle et vérification des propriétés ............. Error! Bookmark not
defined.
IV.2. Le Model Checker LTL de Maude ................. Error! Bookmark not defined.
V.Conclusion................. ..................................................................................................... 38
8
Chapitre II:
La méthode formelle
I.Introduction........................................................................Error! Bookmark not defined.
II.Méthodes de Vérification des systèmes… ..................Error! Bookmark not defined.
II.1 Méthodes Classiques ........................................ Error! Bookmark not defined.
II.2 Méthodes Formelles ......................................... Error! Bookmark not defined.
III.Model-Checking………………………………………..…………………….....
Error! Bookmark not defined.
III.1. Principe ........................................................... Error! Bookmark not defined.
35
III.2. Concepts liés par Model-checking ................ Error! Bookmark not defined.
III.3. Quelques Model-Checkers .............................. Error! Bookmark not defined.
III.3.1. SMV (Symbolic Model Verifier) ............. Error! Bookmark not defined.
III.3.2. SPIN.......................................................... Error! Bookmark not defined.
III.3.3. LTL de MAUDE ...................................... Error! Bookmark not defined.
IV. Le Model Checker LTL de Maude ...........................Error! Bookmark not defined.
V.Conclusion...................... .................................................Error! Bookmark not defined.
Chapitre III:
Méthode B
I.Introduction ....................... .............................................Error! Bookmark not defined.
II.Agent................................. .................................................Error! Bookmark not defined.
II.1. Définition .......................................................... Error! Bookmark not defined.
II.2. Caractéristique d'un agent ................................ Error! Bookmark not defined.
II.3. Types des agents ............................................... Error! Bookmark not defined.
II.3.1. Les agents cognitifs ................................... Error! Bookmark not defined.
II.3.2. Les agents réactifs ..................................... Error! Bookmark not defined.
II.3.3. Les agents hybrides ................................... Error! Bookmark not defined.
III.Système Multi-Agent.....................................................Error! Bookmark not defined.
III.1.Définition ......................................................... Error! Bookmark not defined.
III.2. La Communication dans les Systèmes Multi-Agents ... Error! Bookmark not
defined.
9
III.2.1.Les Modes de Communication .................. Error! Bookmark not defined.
IV.Applications des systèmes Multi-agents ...................Error! Bookmark not defined.
V.Spécification Formelle des Systèmes Multi-Agents .Error! Bookmark not defined.
VI.Conclusion……………….. ...........................................Error! Bookmark not defined.
Chapitre IV:
Eude de cas et Implémentation
I.Introduction........................................................................Error! Bookmark not defined.
II.Méthode de vérification .................................................Error! Bookmark not defined.
II.1. Spécification du système .................................. Error! Bookmark not defined.
II.1.1 Spécification du Modèle ............................. Error! Bookmark not defined.
II.1.2 Spécification des propriétés du système ..... Error! Bookmark not defined.
II.2. Spécification des propriétés à vérifier .............. Error! Bookmark not defined.
II.3. Processus de vérification .................................. Error! Bookmark not defined.
III.Définition des propriétés à vérifier ............................Error! Bookmark not defined.
IV.Conclusion…………………………………………………………………..…...
Error! Bookmark not defined.
Conclusion générale... .........................................................Error! Bookmark not defined.
Annexe I ……………. .........................................................Error! Bookmark not defined.
Annexe II …………….. ......................................................Error! Bookmark not defined.
Bibliographie……………….. ........................................................................................... 88
Webographie………………..............................................................................................111
88
01
Liste des figures et des table
Chapitre I
Figure I.1 : Représentation graphique des règles de déduction .................................... 22
Chapitre II
Figure II.1 : Principe du model checking. ........................................................................ 35
Figure II.2 : Exemple de structure de Kripke. ............................................................ 37
Figure II.2 : L‟architecture du model-checker de MAUDE. ...................................... 38
Chapitre III
Figure III.1 : Architecture d'un agent cognitif. ......................................................... 46
Figure III.2: Architecture d'un agent réactif. .............................................................. 46
Figure III.3 : Système Multi-Agents. ......................................................................... 48
Figure III.4: La technique du tableau noir. ................................................................. 49
Figure III.5 : Communication par envoi de messages. .............................................. 50
Tableau III.1: Différence entre les agents cognitifs et réactifs................................... 47
Chapitre IV
Figure IV.1 : Approche de Spécification et Vérification................................................ 56
Figure IV.2 : L'ordonnancement d'activité. ...................................................................... 57
Figure V.5 : Modèle d'état de transition d‟un Agent communicant ........................... 65
Figure V.6: Résultat de vérification d'absence d'interblocage –Maintenance–........... 70
Figure V.7: Résultat de vérification d'absence de famine ........................................... 70
00
Figure V.8: Résultat de vérification l'état d'arrêt du système...................................... 71
Figure V.9: Modèle d'état de transition d‟un agent communicant –corrigé-. ............ 74
Introduction générale
02
A
vec l'évolution exponentiel des systèmes industriels et le besoin des
systèmes informatique robustes, le développement des produits logiciels
est devenu une tâche très difficile et sa complexité n'a qu'accroître. Par
conséquent, le développement des produits logiciels fait appel à plusieurs techniques
et méthodes dont l'objectif est d‟assurer la bonne qualité du produit final, respecter les
délais et de minimiser les coûts de développement.
En effet, depuis la crise de génie logiciel dans les années 60s, plusieurs efforts ont
été inventés pour améliorer ces techniques et méthodes de développement. Le but
était de répondre aux critères imposés par le marché du logiciel. Les méthodologies
Orientées objet, les langages de programmation, les outils formels, les ateliers
logiciels, sont des variantes de ces efforts.
1. Contexte général et Problématique :
La construction de systèmes de qualité tout en respectant les contraintes de temps
et de budget représente un formidable défi pour les informaticiens. Dans les domaines
où la sécurité des personnes et des biens est en cause, ce défi est encore plus grand.
Une des approches proposées pour résoudre ce problème consiste à utiliser des outils
mathématiques pour spécifier, valider et vérifier les systèmes informatiques. On
désigne communément ces approches basées sur les mathématiques comme des
méthodes formelles. Le choix des mathématiques s‟explique par le besoin de rigueur
et de précision dans la description du comportement de systèmes complexes, et par la
nécessité de disposer de mécanismes d‟abstraction pour juguler la complexité. Les
méthodes formelles permettent également de palier aux faiblesses des méthodes
traditionnelles de tests qui ne peuvent traiter de manière exhaustive tous les cas
possibles d‟utilisation d‟un système.
Après plus de trois décennies de recherches, la communauté scientifique a proposé
plusieurs méthodes formelles de construction de systèmes. Certaines d‟entre elles sont
maintenant utilisées pour concevoir des systèmes en milieu industriel comme le
transport, les télécommunications, l‟énergie nucléaire, les circuits intégrés et les
appareils médicaux. Toutefois, l‟utilisation de méthodes formelles demeure peu
03
répandue, et leur utilisation à grande échelle nécessitera encore plusieurs
investissements au niveau de la recherche, mais également au niveau de la formation
des informaticiens.
Il y a beaucoup de dangers sont causés par des erreurs dans les grandes
applications. Et nous avons consacré de mentionner le langage Java, a un large
éventail de domaines dans leur application, et est l'une des langages communes et
complexe, avec le grand développement de la technologie de notre temps, est devenu
le langage Java manque de précision, et ne donne pas suffisamment de résultats dans
les grandes applications logicielles (telles que les applications sur le train et avion) et
pour cela, nous avons proposé une méthode de résoudre ces complexités et de donner
le débogueur de programme et précise.
2. Objectifs:
Le but de ce travail est de transformer une application (java) à méthode B, pour
valider un cette
système et
aucun erreurs
Spécification formelle; raffiner et
implémenter une spécification.
3. Organisation du mémoire:
Cette thèse se compose de quatre chapitres, qui sont organisés comme suit :
Chapitre I: est consacré à l‟étude le langage java et leur composition pour mieux
comprendre les concepts de base de cette technologie.
Chapitre II: Nous commençons ce chapitre par décrire une présentation des approches
formelles et leur type … Ensuite nous étudions une classification de ces approches
selon leurs fonctions et leur mode de fonctionnement et l‟avantages et l'inconvénient.
Chapitre III: ce chapitre est le cœur de notre travail. Dans ce chapitre nous allons
présenter notre approche formelle (méthode B)
pour la validation
formelle, et
transformer le code java à cette méthode (méthode B).
Chapitre IV: Dans ce chapitre nous présentons une étude de cas et implémentation
pour valider notre travail. Et enfin nous terminons par une conclusion et des
perspectives de notre travail.
04
Chapitre I:
Langage JAVA
05
I. Introduction :
Dans ce chapitre nous allons étudier le langage de programmation Java, est une approche
interdisciplinaire pour le programme traditionnel. En utilisant plusieurs approches qui mettent
l'accent sur l'abstraction de données. Une caractéristique clé du chapitre est la manière dont nous
motivons chaque concept de programmation en examinant son impact sur les applications
spécifiques. Ainsi, nous allons en apprendre davantage sur la façon de les utiliser, Les notions et
les techniques de base en Java, Les caractéristiques, les instructions des bases JAVA et
Développement des interfaces graphiques...etc
II. Les bases du langage Java :
II.1. représentation de java:
Java est un langage de programmation à usage général, évolué et orienté objet dont la
syntaxe est proche du C. Ses caractéristiques ainsi que la richesse de son écosystème et de sa
communauté lui ont permis d'être très largement utilisé pour le développement d'applications de
types très disparates. Java est notamment largement utilisée pour le développement d'applications
d'entreprises et mobiles.

Les différentes éditions et versions de Java sont:
Le JRE (Java Runtime Environment) contient uniquement l'environnement d'exécution de
programmes Java. Le JDK contient lui-même le JRE. Le JRE seul doit être installé sur les
machines où des applications Java doivent être exécutées.
Depuis sa version 1.2, Java a été renommé Java 2. Les numéros de version 1.2 et 2 désignent
donc la même version. Le JDK a été renommé J2SDK (Java 2 Software Développent Kit) mais la
dénomination JDK reste encore largement utilisée, à tel point que la dénomination JDK est reprise
dans la version 5.0. Le JRE a été renommé J2RE (Java 2 Runtime Environnent). [MD.14]
Trois plates-formes d'exécution (ou éditions) Java sont définies pour des cibles distinctes selon
les besoins des applications à développer :
06
 Java Standard Edition (J2SE / Java SE) : environnement d'exécution et ensemble complet d'API
pour des applications de type desktop. Cette plate-forme sert de base en tout ou partie aux autres
plates-formes.

Java Enterprise Edition (J2EE / Java EE) : environnement d'exécution reposant intégralement
sur Java SE pour le développement d'applications d'entreprises.
 Java Micro Edition (J2ME / Java ME) : environnement d'exécution et API pour le
développement d'applications sur appareils mobiles et embarqués dont les capacités ne
permettent pas la mise en œuvre de Java SE.
La séparation en trois plates-formes permet au développeur de mieux cibler l'environnement
d'exécution et de faire évoluer les plates-formes de façon plus indépendante.

Avec différentes éditions, les types d'applications qui peuvent être développées en Java
sont nombreux et variés :

Applications desktop.

Applications web: servlets/JSP, portlets, applets.

Applications pour appareil mobile (MIDP) : midlets.

Applications pour appareil embarqué (CDC).

Applications pour carte à puce (Javacard) : applets Javacard.

Applications temps reel.

Sun fournit le JDK, à partir de la version 1.2, pour les plates-formes Windows, Solaris et
Linux.

La version 1.3 de Java est désignée sous le nom Java 2 version 1.3.

La version 1.5 de Java est désignée officiellement sous le nom J2SE version 5.0.

La version 6 de Java est désignée officiellement sous le nom Java SE version 6.
II.2. Les caractéristiques:
Java possède un certain nombre de caractéristiques qui ont largement contribué à son énorme
succès :
07

Java est interprété :
La source est compilé en pseudo code ou bytecode puis exécuté par un interpréteur Java ; la Java
Virtual Machine (JVM). Ce concept est à la base du slogan de Sun pour Java :WORA (Write Once,
Run Anywhere : écrire une fois, exécuter partout). En effet, le bytecode, s'il ne contient pas de code
spécifique à une plate-forme particulière peut être exécuté et obtenir quasiment les mêmes résultats
sur toutes les machines disposant d'une JVM.

Java est portable :
Il est indépendant de toute plate-forme :
 Il n'y a pas de compilation spécifique pour chaque plate-forme. Le code reste indépendant de
la machine sur laquelle il s'exécute.
 Il est possible d'exécuter des programmes Java sur tous les environnements qui possèdent une
Java Virtual Machine. Cette indépendance est assurée au niveau du code source grâce à
Unicode et au niveau du bytecode.

Java est orienté objet :
Comme la plupart des langages récents, Java est orienté objet. Chaque fichier source contient la
définition d'une ou plusieurs classes qui sont utilisées les unes avec les autres pour former une
application. Java n'est pas complètement objet car il définit des types primitifs (entier, caractère,
flottant, booléen...).

Java est simple :
Le choix de ses auteurs a été d'abandonner des éléments mal compris ou mal exploités
des autres langages tels que la notion de pointeurs (pour éviter les incidents en manipulant
directement la mémoire), l'héritage multiple et la surcharge des opérateurs...

Java est fortement type :
Toutes les variables sont typées et il n'existe pas de conversion automatique qui
risquerait une perte de données. Si une telle conversion doit être réalisée, le développeur doit
obligatoirement utiliser un cast ou une méthode statique fournie en standard pour la réaliser.
08

Java assure la gestion de la mémoire :
L'allocation de la mémoire pour un objet est automatique à sa création et Java récupère
automatiquement la mémoire inutilisée grâce au garbage collector qui restitue les zones de mémoire
laissées libres suite à la destruction des objets.

Java est sûr:
La sécurité fait partie intégrante du système d'exécution et du compilateur. Un programme Java
planté ne menace pas le système d'exploitation. Il ne peut pas y avoir d'accès direct à la mémoire.
L'accès au disque dur est réglementé dans une applet. Les applets fonctionnant sur le Web sont
soumises aux restrictions suivantes dans la version 1.0 de Java :
 Aucun programme ne peut ouvrir, lire, écrire ou effacer un fichier sur le système de l'utilisateur
 Aucun programme ne peut lancer un autre programme sur le système de l'utilisateur.
 Toute fenêtre créée par le programme est clairement identifiée comme étant une fenêtre Java,
ce qui interdit par exemple la création d'une fausse fenêtre demandant un mot de passe.
Les programmes ne peuvent pas se connecter à d'autres sites Web que celui dont ils proviennent.

Java est économe:
Le pseudo code à une taille relativement petite car les bibliothèques de classes requises ne sont
liées qu'à l'exécution.

Java est multitâche:
Il permet l'utilisation de threads qui sont des unités d'exécutions isolées. La JVM, elle-même,
utilise plusieurs threads.
II.3. Les notions et les techniques de base en Java:
Cette note présente quelques concepts de base utilisés en Java relatifs à la compilation et
l'exécution d'applications, notamment, les notions de classpath, de packages et d'archives de
déploiement jar.
II.3.1. Les concepts de base:
09
La plate-forme Java utilise quelques notions de base lors de sa mise en œuvre, notamment :

La compilation du code source dans un langage indépendant de la plate-forme d'exécution : le
bytecode.

l'exécution du bytecode par une machine virtuelle nommée JVM (Java Virtual Machine).

la notion de package qui permet d'organiser les classes.

le classpath qui permet de préciser au compilateur et à la JVM où elle peut trouver les classes
requises par l'application.

le packaging des classes compilées dans une archive de déploiement nommée jar (Java
ARchive). [MD.14]
II.3.2. L'exécution d'une applet:
Un programme Java est composé d'un ou plus généralement plusieurs fichiers source.
N'importe quel éditeur de texte peut être utilisé pour éditer un fichier source Java.
Ces fichiers source possèdent l'extension .java. Ils peuvent contenir une ou plusieurs classes
ou interfaces mais il ne peut y avoir qu'une seule classe ou interface déclarée publique par fichier.
Le nom de ce fichier source doit obligatoirement correspondre à la casse près au nom de cette entité
publique suivi de l'extension .java
Il est nécessaire de compiler la source pour le transformer en J-code ou bytecode Java qui sera
lui exécuté par la machine virtuelle. Pour être compilé, le programme doit être enregistré au format
de caractères Unicode : une conversion automatique est faite par le JDK si nécessaire.
Un compilateur Java, par exemple l'outil java fourni avec le JDK est utilisé pour compiler
chaque fichier source en fichier de classe possédant l'extension .class. Cette compilation gère pour
chaque fichier source un ou plusieurs fichiers .class qui contiennent du bytecode.
Figure I.1 : test java
21
III. les instructions des bases JAVA :
III.1. instructions-bloc:
Une large partie de la norme ANSI du langage C est reprise dans Java.

Les commentaires sur une ligne débutent par //....
 Les commentaires sur plusieurs lignes sont encadrés par /* ... */
Dans ce sous-chapitre nous expliquons les instructions Java en le comparant à pascal-Delphi.
Voici la syntaxe d'une instruction en Java :
III.1.1.instruction :
Figure I.2 : instruction
III.1.2.instruction complète :
Figure I.3 : instruction complète
Toutes les instructions se terminent donc en Java par un point-virgule " ; "
III.1.3. bloc - instruction composée :
20
Figure I.3 : instruction composée
L'élément syntaxique est aussi dénommé bloc ou instruction composée au sens de
la visibilité des variables Java.
III.1.4. visibilité dans un bloc - instruction:
Exemple de déclarations licites et de visibilité dans 3 blocs instruction imbriqués :
int a, b = 12;
{ int x , y = 8 ;
{ int z =12;
x=z;
a=x+1;
{ int u = 1 ;
y=u-b;
}
}
}
schéma d'imbrication des 3 blocs
Nous examinons ci-dessous l'ensemble des instructions simples de Java.
III.2. L'affectation:
Java est un langage de la famille des langages hybrides, il possède la notion d'instruction
d'affectation.
Le symbole d'affectation en Java est " = ", soit par exemple :
22
x=y;
// x doit obligatoirement être un identificateur de variable.
III.2.1. Affectation simple:
L'affectation peut être utilisée dans une expression :

soient les instructions suivantes :
int a, b = 56 ;
a = (b = 12) +8 ; // b prend une nouvelle valeur dans l'expression
a = b = c = d =8 ; // affectation multiple
 simulation d'exécution Java :
instruction
valeur de a valeur de b
int a , b = 56 ;
a = ???
b = 56
a = (b = 12)+8 ;
a = 20
b = 12
III.2.2 Raccourcis et opérateurs d'affectation:
Soit op un opérateur appartenant à l'ensemble des opérateurs suivant { +, - , * , / , %, << , >> ,
>>> , & , | , ^ }, il est possible d'utiliser sur une seule variable le nouvel opérateur op= construit
avec l'opérateur op. Il s'agit plus d'un raccourci syntaxique que d'un opérateur nouveau (seule sa
traduction en bytecode diffère : la traduction de a op= b devrait être plus courte en instructions pcode que a = a op b, bien que les optimiseurs soient capables de fournir le même code optimisé).
x op= y ;
signifie en fait : x = x op y
 soient les instructions suivantes :
int a, b = 56 ;
a = -8 ;
a += b ; // équivalent à : a = a + b
b *= 3 ; // équivalent à : b = b * 3
 simulation d'exécution Java :
instruction
valeur de a
valeur de b
int a , b = 56 ;
a = ???
b = 56
23
a = -8 ;
a = -8
b = 56
a += b ;
a = 48
b = 56
b *= 3 ;
a = 48
b = 168
III.3. Les conditions:
III.3.1 les instructions conditionnelles :
Syntaxe :
Figure I.3 : instructions conditionnelles.
Schématiquement les conditions sont de deux sortes :


if ( Expr ) Instr ;
if ( Expr ) Instr ; else Instr ;
La définition de l'instruction conditionnelle de java est classiquement celle des langages
algorithmiques; comme en pascal l'expression doit être de type booléen (différent du C), la notion
d'instruction a été définie plus haut.
III.3.2 l'opérateur conditionnel :
Il s'agit ici comme dans le cas des opérateurs d'affectation d'une sorte de raccourci entre
l'opérateur conditionnel if...else et l'affectation. Le but étant encore d'optimiser le bytecode
engendré.
Syntaxe :
Figure I.4 : Opérateur conditionnel.
24
Où expression renvoie une valeur booléenne (le test), les deux termes valeur sont des
expressions générales (variable, expression numérique, booléenne, etc...) renvoyant une valeur de
type quelconque.
Sémantique :
Exemple :
int a,b,c ;
c = a = = 0 ? b : a+1 ;
Si l'expression est true l'opérateur renvoie la première valeur, (dans l'exemple c vaut la valeur de b).
Si l'expression est false l'opérateur renvoie la seconde valeur (dans l'exemple c vaut la valeur de
a+1).
Sémantique de l'exemple avec un if..else :
if (a = = 0) c = b;
else c = a+1;
III.4. Les itérations:
III.4.1.Itération while :
Syntaxe :
Figure I.5 : Itération while.
Où expression est une expression renvoyant une valeur booléenne (le test de l'itération).
Sémantique :
Identique à celle du pascal (instruction algorithmique tantque .. faire .. ftant) avec le même défaut
de fermeture de la boucle.
III.4.2.Itération do...while :
25
Syntaxe :
Où expression est une expression renvoyant une valeur booléenne (le test de l'itération).
Sémantique :
"do Instr while ( Expr )" fonctionne comme l'instruction
algorithmique répéter Instr jusquà non Expr.
Sa sémantique peut aussi être expliquée à l'aide d'une autre instruction Java while :
do Instr while ( Expr )  Instr ; while ( Expr ) Instr
Exemple de boucle do...while
III.4.3.Itération for :
Syntaxe :
Sémantique :
Une boucle for contient 3 expressions for (Expr1 ; Expr2 ; Expr3 ) Instr , d'une manière générale
chacune de ces expressions joue un rôle différent dans l'instruction for. Une instruction for en Java
(comme en C) est plus puissante et plus riche qu'une boucle for dans d'autres langages
algorithmiques. Nous donnons ci-après une sémantique minimale :

Expr1 sert à initialiser une ou plusieurs variables (dont éventuellement la variable de
contrôle de la boucle) sous forme d'une liste d'instructions d'initialisation séparées par des virgules.

Expr2 sert à donner la condition de rebouclage sous la fome d'une expression renvoyant
une valeur booléenne (le test de l'itération).

Expr3 sert à réactualiser les variables (dont éventuellement la variable de contrôle de la
boucle) sous forme d'une liste d'instructions séparées par des virgules.
26
"for(Expr1 ; Expr2 ; Expr3) Instr" fonctionne au minimum comme l'instruction
algorithmique pour... fpour.
Sa sémantique peut aussi être approximativement(*) expliquée à l'aide d'une autre instruction
Java while :
for (Expr1 ; Expr2 ; Expr3 ) Instr 
Expr1 ;
while (Expr2)
{Instr ;
Expr3
}
(*)Nous verrons au paragraphe consacré à l'instruction continue que si l'instruction for contient
un continue cette définition sémantique n'est pas valide.
III.5. Break et continue :
III.5.1.Interruption break :
Syntaxe :
Sémantique:
Une instruction break ne peut se situer qu'à l'intérieur du corps d'instruction d'un bloc switch (le
switch est traité au paragraphe suivant), ou de l'une des trois itérations while, do..while, for.
Lorsque break est présente dans l'une des trois itérations while, do..while, for :

Si break n'est pas suivi d'une étiquette elle interrompt l'exécution de la boucle dans
laquelle elle se trouve, l'exécution se poursuit après le corps d'instruction.
27

Si break est
suivi
d'une
étiquette
elle
fonctionne
comme
un goto (utilisation déconseillée en programmation moderne sauf pour le switch, c'est pourquoi
nous n'en dirons pas plus pour les boucles !)
III.5.2.Rebouclage continue :
Syntaxe :
Sémantique :
Une instruction continue ne peut se situer qu'à l'intérieur du corps d'instruction de l'une des trois
itérations while, do..while, for.
Lorsque continue est présente dans l'une des trois itérations while, do..while, for :

Si continue n'est pas suivi d'une étiquette elle interrompt l'exécution de la séquence des
instructions situées après elle, l'exécution par rebouclage de la boucle. Elle agit comme si l'on venait
d'exécuter la dernière instruction du corps de la boucle.

Si continue est
suivi
d'une
étiquette
elle
fonctionne
comme
un goto (utilisation déconseillée en programmation moderne, c'est pourquoi nous n'en dirons pas
plus !)
III.6. Switch...case:
Syntaxe:
Bloc Switch :
28
Sémantique:
La partie expression d'une instruction switch doit être une expression ou une variable du
type byte, char, int ou bien short.
La partie expression d'un bloc switch doit être une constante ou une valeur immédiate du
type byte, char, int ou bien short.
switch <Epr1> s'appelle la partie sélection de l'instruction : il y a évaluation de <Epr1> puis
selon la valeur obtenue le programme s'exécute en séquence à partir du case contenant la valeur
immédiate égal. Il s'agit donc d'un déroutement du programme dès que <Epr1> est évaluée vers
l'instruction étiquetée par le case <Epr1> associé.
III.7. try...catch :
Nous reviendrons plus loin sur les exceptions et l'instruction try...catch. Nous donnons ici la
syntaxe d'une version simple et nous indiquons que sa sémantique est semblable à celle du
bloc try…exceptde Delphi. Sachons pour l'instant que Java dispose d'un mécanisme puissant
présent dans les langages robustes Ada, C++, Delphi pour intercepter et traiter les erreurs ou
incidents survenant dans un bloc d'instruction. [web.01]

L'instruction try...catch sert à traiter de tels incidents, elle dispose d'un bloc try (pour les
instructions à protéger) et d'un ou plusieurs blocs catch (pour divers genres de traitement en cas
d'incidents).

try {
BLOC à protéger
}
catch (TypeErreur1 Err1) {
TRAITEMENT d'une erreur du type TypeErreur1
}
catch (TypeErreur2 Err2) {
TRAITEMENT d'une erreur du type TypeErreur2
}
...
catch (TypeErreurX ErrX) {
TRAITEMENT d'une erreur du type TypeErreurX
}
29
IV. Développement des interfaces graphiques:
Les interfaces graphiques assurent le dialogue entre les utilisateurs et une application.
Dans un premier temps, Java proposait l'API AWT pour créer des interfaces graphiques.
Depuis, Java propose une nouvelle API nommée Swing. Ces deux API peuvent être utilisées pour
développer des applications ou des applets. Face aux problèmes de performance de Swing, IBM a
créé sa propre bibliothèque nommée SWT utilisée pour développer l'outil Eclipse. La vélocité de
cette application favorise une utilisation grandissante de cette bibliothèque.
Les développements des interfaces graphiques contient les point suivants:

Le graphisme : Ensemble des techniques de dessin et leurs résultats, leur mise en œuvre.
Les graphismes d'un jeu sont toutes les images, tous les dessins, tout le travail graphique par
opposition au reste (son, codage...). [web.02]

Les éléments d'interfaces graphiques de l'AWT: Les classes du toolkit AWT (Abstract
Windows Toolkit) permettent d'écrire des interfaces graphiques indépendantes du système
d'exploitation sur lesquel elles vont fonctionner. Cette librairie utilise le système graphique de la
plate-forme d'exécution (Windows, MacOS, X-Window) pour afficher les objets graphiques. Le
toolkit contient des classes décrivant les composants graphiques, les polices, les couleurs et les
images.

La création d'interfaces graphiques avec AWT: AWT propose un ensemble de
composants et de fonctionnalités pour créer des interfaces graphiques.

L'interception des actions de l'utilisateur: N'importe quelle interface graphique doit
interagir avec l'utilisateur et donc réagir à certains événements. Le modèle de gestion de ces
événements à changer entre le JDK 1.0 et 1.1.

Le développement d'interfaces graphiques avec SWING: Swing fait partie de la
bibliothèque Java Fondation Classes (JFC). C'est une API dont le but est similaire à celui de l'API
AWT mais dont les modes de fonctionnement et d'utilisation sont complètement différents. Swing a
été intégré au JDK depuis sa version 1.2. Cette bibliothèque existe séparément. Pour le JDK 1.1.
La bibliothèque JFC contient:
31

L‟API Swing : de nouvelles classes et interfaces pour construire des interfaces
graphiques.

Accessibility API.

2D API: support du graphisme en 2D.

API pour l'impression et le cliquer/glisser.

Structure d’un programme Java-Swing

Un programme Java-Swing est composé d‟un ensemble de widgets.

A ces widgets peuvent être associés des listeners d‟évènements.

Un listener d‟évènements implémente des méthodes. Suivant le type d‟événement produit
par l‟action de l‟utilisateur sur un widget, la "bonne" méthode de listener est exécutée.

Méthode de listener : le corps d‟une méthode de listener modifie le rendu de l‟interface et
effectue des calculs par appel au noyau fonctionnel de l‟application.

Le développement d'interfaces graphiques avec SWT: La première API pour développer
des interfaces graphiques portables d'un système à un autre en Java est AWT. Cette API repose sur
les composants graphiques du système sous-jacent ce qui lui assure de bonnes performances.
Malheureusement, ces composants sont limités dans leur fonctionnalité car ils représentent le plus
petit dénominateur commun des différents systèmes concernés.
Pour pallier ce problème, Sun a proposé une nouvelle API, Swing. Cette Api est presque
exclusivement écrite en Java, ce qui assure sa portabilité. Swing possède aussi d'autres points forts,
telles que des fonctionnalités avancées, la possibilité d'étendre les composants, une adaptation du
rendu de composants, etc ... Swing est une API mature, éprouvée et parfaitement connue.
Malheureusement, ses deux gros défauts sont sa consommation en ressource machine et la lenteur
d'exécution des applications qui l'utilisent.
SWT propose une approche intermédiaire : utiliser autant que possible les composants du
système et implémenter les autres composants en Java. SWT est écrit en Java et utilise la
technologie JNI pour appeler les composants natifs. SWT utilise autant que possible les composants
natifs du système lorsqu'ils existent, sinon ils sont réécrits en pur Java. Les données de chaque
30
composant sont aussi stockées autant que possible dans le composant natif, limitant ainsi les
données stockées dans les objets Java correspondant.
JFace : JFace est une bibliothèque graphique libre Java pour le projet Eclipse qui s'appuie sur la
bibliothèque SWT pour fournir des interfaces utilitaires plus structurées.
IV.1. Les API avancées:
Le JDK fournit un certain nombre d'API intégrés au JDK pour des fonctionnalités avancées.
Les API avancées contient les point suivants:

Les collections : Les collections sont des objets qui permettent de gérer des ensembles
d'objets. Ces ensembles de données peuvent être définis avec plusieurs caractéristiques : la
possibilité de gérer des doublons, de gérer un ordre de tri, etc. ...

Les flux : Un programme a souvent besoin d'échanger des informations, que ce soit pour
recevoir des données d'une source ou pour envoyer des données vers un destinataire.
La source et la destination de ces échanges peuvent être de natures multiples : un fichier, un
socket réseau, un autre programme, etc ...
De la même façon, la nature des données échangées peut être diverse : du texte, des images, du
son, etc ...

NIO 2 : L‟API NIO 2 a été développée sous la JSR 203 et a été ajoutée au JDK dans la
version 7 de Java SE. NIO 2 est une API plus moderne et plus complète pour l'accès au système de
fichiers. Son but est en partie de remplacer la classe File de la très ancienne API IO.
NIO 2 propose d'étendre les fonctionnalités relatives aux entrées/sorties : l'utilisation du système
de fichiers de manière facile et les lectures/écritures asynchrones.

La sérialisation : La sérialisation est un procédé introduit dans le JDK version 1.1 qui
permet de rendre un objet ou un graphe d'objets de la JVM persistant pour stockage ou échange et
vice versa. Cet objet est mis sous une forme sous laquelle il pourra être reconstitué à l'identique.
Ainsi il pourra être stocké sur un disque dur ou transmis au travers d'un réseau pour le créer dans
32
une autre JVM. C'est le procédé qui est utilisé, par exemple, par RMI. La sérialisation est aussi
utilisée par les beans pour sauvegarder leurs états.

L'interaction avec le réseau : Les échanges avec le réseau sont devenus omniprésents
dans les applications et entre les applications. Ils permettent notamment :

un accès à des serveurs comme une base de données

d'invoquer des services distants

de développer des applications web

d'échanger des données entres applications
La plupart de ces fonctionnalités sont mises en oeuvre via des API de haut niveau mais celles-ci
utilisent généralement des API de bas niveau pour interagir avec le réseau.

La gestion dynamique des objets et l'introspection : Depuis la version 1.1 de Java, il
est possible de créer et de gérer dynamiquement des objets.
L'introspection est un mécanisme qui permet de connaître le contenu d'une classe
dynamiquement. Il permet notamment de savoir ce que contient une classe sans en avoir les
sources. Ces mécanismes sont largement utilisés dans des outils de type IDE (Integrated
Development Environnement : environnement de développement intégré).

L'appel de méthodes distantes : RMI (Remote Method Invocation) est une technologie
développée et fournie par Sun à partir du JDK 1.1 pour permettre de mettre en oeuvre facilement
des objets distribués.

L'internationalisation: La localisation consiste à adapter un logiciel aux caractéristiques
locales de l'environnement d'exécution telles que la langue et la monnaie. Le plus gros du travail
consiste à traduire toutes les phrases et les mots. Les classes nécessaires sont incluses dans le
packetage java.util.

Les composants Java beans :
Les JavaBeans sont des composants réutilisables
introduits par le JDK 1.1. De nombreuses fonctionnalités ont ensuite été ajoutées pour développer
des caractéristiques de ces composants. Les JavaBeans sont couramment appelés beans tout
simplement.
33
Les beans sont prévus pour pouvoir interagir avec d'autres beans au point de pouvoir développer
une application simplement en assemblant des beans avec un outil graphique dédié. Sun fournit
gratuitement un tel outil : le B.D.K. (Bean Development Kit).

Le logging : Le logging consiste à ajouter des traitements dans les applications pour
permettre l'émission et le stockage de messages suite à des événements.
Le logging est utile pour tous les types d'applications en permettant par exemple de conserver
une trace des exceptions qui sont levées dans l'application et des différents événements anormaux
ou normaux liés à l'exécution de l'application.
Le logging permet de gérer des messages émis par une application durant son exécution et de
permettre leur exploitation immédiate ou a postériori. Ces messages sont d'ailleurs très utiles lors de
la mise au point d'une application ou lors de son exploitation pour comprendre son fonctionnement
ou résoudre une anomalie.

La sécurité : Depuis sa conception, la sécurité dans le langage Java a toujours été une
grande préoccupation pour Sun.
Avec Java, la sécurité revêt de nombreux aspects :

les spécifications du langage disposent de fonctionnalités pour renforcer la sécurité du
code.

la plate-forme définit un modèle pour gérer les droits d'une application

les API JCA/JCE permettent d'utiliser des technologies de cryptographie

l'API JSSE permet d'utiliser le réseau au travers des protocoles sécurisés SSL ou TLS.

l'API JAAS propose un service pour gérer l'authentification et les autorisations d'un
utilisateur.

JCA (Java Cryptography Architecture) : Le but de l'API JCA (Java Cryptography
Architecture) est de fournir des fonctionnalités cryptographiques de base à la plate-forme Java.
34

JCE (Java Cryptography Extension : L'API JCE (Java Cryptography Extension) est
une extension de JCA qui lui ajoute des API pour l'encryptage et le décryptage, la génération de
clés et l'authentification de messages avec des algorithmes de type MAC.

JNI (Java Native Interface) : JNI est l'acronyme de Java Native Interface. C'est une
technologie qui permet d'utiliser du code natif, notamment C, dans une classe Java.

JNDI (Java Naming and Directory Interface) : JNDI est l'acronyme de Java Naming
and Directory Interface. Cette API fournit une interface unique pour utiliser différents services de
nommages ou d'annuaires et définit une API standard pour permettre l'accès à ces services.

Le scripting : Le scripting est utilisé depuis longtemps, dans un premier temps, pour
automatiser certaines tâches sur des systèmes d'exploitation (exemple le shell sous Linux) puis sous
la forme de langages de développement (exemple Perl, Python, ...)
Ces langages n'ont pas pour but de remplacer le langage Java mais ils peuvent avoir une place de
choix pour remplir certaines tâches et permettre de bénéficier des points forts de Java et du
scripting.

JMX (Java Management Extensions) : JMX est l'acronyme de Java Management
Extensions. Historiquement, cette API se nommait JMAPI (Java Management API). La version 5.0
de Java a ajouté l'API JMX 1.2 dans la bibliothèque de classes standard.
JMX est une spécification qui définit une architecture, une API et des services pour permettre de
surveiller et de gérer des ressources en Java. JMX permet de mettre en place, en utilisant un
standard, un système de surveillance et de gestion d'une application, d'un service ou d'une ressource
sans avoir à fournir beaucoup d'efforts.
V. Le développement d'applications java web :
Le développement d'applications java web contient les points suivants:

Les servlets : A la base, les serveurs web sont seulement capables de renvoyer des
fichiers présents sur le serveur en réponse à une requête d'un client. Cependant, pour permettre
l'envoi d'une page HTML contenant par exemple une liste d'articles répondant à différents critères,
35
il faut créer dynamiquement cette page HTML. Plusieurs solutions existent pour ces traitements.
Les servlets Java sont une de ces solutions.
Mais les servlets peuvent aussi servir à d'autres usages.

Les JSP (Java Server Pages) : Les JSP (Java Server Pages) sont une technologie Java
qui permet la génération de pages web dynamiques.
La technologie JSP permet de séparer la présentation sous forme de code HTML et les
traitements écrits en Java sous la forme de JavBeans ou de servlets. Ceci est d'autant plus facile que
les JSP définissent une syntaxe particulière permettant d'appeler un bean et d'insérer le résultat de
son traitement dans la page HTML dynamiquement.

JSTL (Java server page Standard Tag Library) : JSTL est l'acronyme de Java server
page Standard Tag Library. C'est un ensemble de tags personnalisés développé sous la JSR 052 qui
propose des fonctionnalités souvent rencontrées dans les JSP :

Tag de structure (itération, conditionnement ...)

Internationalisation

Exécution de requêtes SQL

Utilisation de documents XML

Struts : Struts est un framework pour applications web développé par le projet Jakarta de
la fondation Apache. C'est le plus populaire des frameworks pour le développement d'applications
web avec Java.

JSF (Java Server Faces) : Java Server Faces (JSF) est une technologie dont le but est de
proposer un framework qui facilite et standardise le développement d'applications web avec Java.
Son développement a tenu compte des différentes expériences acquises lors de l'utilisation des
technologies standard pour le développement d'applications web (servlet, JSP, JSTL) et de
différents frameworks (Struts, ...)

D'autres frameworks pour les applications web : En plus des solutions officielles de la
plate-forme Java EE, servlets/JSP et JSF, l'écosystème Java dispose de nombreuses solutions pour
le développements d'applications web. Ce chapitre propose une liste non exhaustive de ces
solutions.
36
VI. Les outils pour le développement JAVA :
Le développement dans n'importe quel langage nécessite un ou plusieurs outils. D'ailleurs la
multitude des technologies mises en oeuvre dans les projets récents nécessite l'usage de nombreux
outils.
On propose un recensement non exhaustif des outils utilisables pour le développement
d'applications Java et une présentation détaillée de certains d'entre-eux.
Le JDK fournit un ensemble d'outils pour réaliser les développements mais leurs fonctionnalités
se veulent volontairement limitées au strict miminum.
Enfin, le monde open source propose de nombreux outils très utiles.
Il y a beaucoup des outils, nous rappelons quelques:

Les outils du J.D.K. : Le JDK de Sun/Oracle fournit un ensemble d'outils qui permettent
de réaliser des applications. Ces outils sont peu ergonomiques car ils s'utilisent en ligne de
commandes mais, en contrepartie, ils peuvent toujours être utilisés.
avaDoc : Javadoc est un outil fourni par Sun avec le JDK pour permettre la génération d'une
documentation technique à partir du code source.
Cet outil génère une documentation au format HTML à partir du code source Java et des
commentaires particuliers qu'il contient. Un exemple concret de l'utilisation de cet outil est la
documentation du JDK qui est générée grâce à Javadoc.

Les outils libres et commerciaux : tente une énumération non exhaustive des outils
libres et commerciaux pour utiliser java.

Ant : Ant est un projet du groupe Apache-Jakarta. Son but est de fournir un outil écrit en
Java pour permettre la construction d'applications (compilation, exécution de tâches post et pré
compilation, ...). Ces processus de construction d'applications sont très importants car ils permettent
d'automatiser des opérations répétitives tout au long du cycle de développement de l'application
(développement, tests, recettes, mises en production, ...)
37

Maven : est un outil de construction de projets (build) open source développé par la
fondation Apache, initialement pour les besoins du projet Jakarta Turbine. Il permet de faciliter et
d'automatiser certaines tâches de la gestion d'un projet Java.

Tomcat : Apache Tomcat est une implémentation open source d'un conteneur web qui
permet donc d'exécuter des applications web reposant sur les technolgoies servlets et JSP.

Des outils open source pour faciliter le développement : présentation de quelques
outils de la communauté open source permettant de simplifier le travail des développeurs.
VII. Conclusion:
Dans ce chapitre nous avons représentez les fondements du langage Java. La maîtrise de ces
notions est indispensable pour produire des applications ou des bibliothèques convenables.
Néanmoins, Nous avons fourni diverses informations important dans l'application de tout
programme en Java, et ensuite nous allons étudier la méthode formelle qui permet de donner un
programme sans erreur.
38
Chapitre II:
Les approches formelles existantes
39
I. Introduction :
1.
En informatique, les méthodes formelles sont des techniques permettant de
raisonner rigoureusement, à l'aide de logique mathématique, sur des programmes informatiques ou
du matériel électroniques, afin de démontrer leur validité par rapport à une certaine spécification.
Elles sont basées sur les sémantiques des programmes, c'est-à-dire sur des descriptions
mathématiques formelles du sens d'un programme donné par son code source (ou parfois, son code
objet).
2.
Dans cette section, nous étudions les approches formelles et nous donner des
exemples d'entre eux et toucher ainsi que d'identifier les types et aspects avantage et négatifs et les
champs d'utilisation de chacun d'eux
3.
II. les méthodes formelles :
II.1. Motivation :
Les méthodes formelles, issues des travaux du Programming Research Group de l'université
d'Oxford, ont été proposées afin d'exprimer le besoin par un formalisme rigoureux, permettant de:

Définir correctement les termes employés et faire abstraction des détails de programmation (pour
ne retenir que les caractéristiques essentielles), et donc limiter au maximum les incompréhensions entre
développeurs et utilisateurs.

Faciliter la preuve de propriétés, et par conséquent la validation des logiciels produits.
II.2. Définition :
Une spécification formelle est exprimée dans un langage à syntaxe et sémantique précises,
construit sur une base théorique solide et permettant des vérifications automatisées : grâce aux
règles de déduction du système formel, on peut démontrer des propriétés de la spécification. Des
exemples de cette technique sont : les réseaux de Petri, les grammaires formelles, les automates à
états
finis,
la
théorie
des
graphes
et
le λcalcul.
Un projet est structuré par à un ensemble de relations entre les spécifications, et certaines de ces
relations peuvent être prouvées formellement [4].
41
II.3. Classification :
On peut classer les méthodes formelles en quatres catégories :
Approche algébrique :
Types abstraits de données (aucune structure de donnée n'est décrite, seules les opérations le
sont), déduction équationnelle : SACSO, LARCH, LPG, OBJ.
Approche dynamique :
Modélisation de l'interaction entre différents processus : CSP, CCS.
Approche logique :
Théorie des types et logiques d'ordre supérieur : PVS, Isabelle/HOL, Coq.
Approche par modèle abstrait :
Définition d'une structure de données et d'un ensemble d'opérations, approche constructive
: VDM, Z, B.
Exemple :
Comment vérifier que l'identité (a+b)2 = a2 + b2 + 2(a*b) est correct?
Une vérification naïve pourrait consister à examiner toutes les valeurs possibles de a, à les
croiser avec toutes les valeurs possibles de b et, pour chaque couple, à calculer (a+b) 2, puis (a+b)2 =
a2 + b2 + 2(a*b) et à s'assurer que l'on obtient le même résultat. Si les domaines de a et de b sont
grands, cette vérification peut être très longue. Et si les domaines sont infinis (par exemple les
réels), cette vérification ne peut pas être exhaustive.
En vérification formelle, on utilise des valeurs symboliques et on applique les règles qui
régissent le + et l'*. Ici, les règles pourraient être:




40
En se servant de ces règles, on arrive à montrer que :
.
Demonstration:
(a+b)² = (a+b) * (a + b)
(R1)
= (a+b) *a + (a+b) * b
(R2)
= a * (a+b) + b * (a+b) (R3)
=a*a+a*b+b*a+b*b
= a² + a * b + b * a + b²
(R1)
= a² + a * b + a * b + b²
(R3)
= a² + 2(a * b) + b²
(R4)
= a² + b² + 2(a * b)
(R5)
(R2)
III. différentes approches :
La vérification comprend plusieurs approches, souvent complémentaires : il existe 2 types
d'approche formelle (les approches formelles ET les approches semi formelles)
4.
5.
III.1.1. Model Checking:
Désigne une famille de techniques de vérification automatique des systèmes
dynamiques (souvent d'origine informatique ou électronique). Il s'agit de vérifier algorithmiquement
si un modèle donné, le système lui-même ou une abstraction du système, satisfait une spécification,
souvent formulée en termes de logique temporelle.
On peut distinguer deux aspects du model checking :

Il peut s'agir de démontrer qu'une certaine classe de propriétés, ou une certaine logique,
est décidable, ou que sa décision appartient à une certaine classe de complexité.

Il peut s'agir de rechercher des algorithmes efficaces sur des cas intéressants en pratique,
de les implémenter, et de les appliquer à des problèmes réels.
Les premiers travaux sur le model checking de formules de logique temporelle ont été menés
par Edmund M. Clarke et E. Allen Emerson en 1981, ainsi que par Jean-Pierre Queille et Joseph
42
Sifakis en 1982. Clarke, Emerson et Sifakis se sont vu attribuer le Prix Turing 2007 pour leurs
travaux sur le model checking. [5]

Les avantages du model checking:

C‟est une approche de vérification générale applicable à un large éventail d‟applications
telles que les systèmes embarqués, le génie logiciel, et la conception matérielle.

Elle supporte une vérification partielle c'est-à-dire les propriétés peuvent être vérifiée
individuellement, permettant ainsi de se concentrer sur les propriétés essentielles dans un premier temps.
Aucune nécessité de spécification complète n‟est nécessaire.

Il n‟est pas vulnérable à la probabilité avec laquelle une erreur est exposée, ce qui contraste avec
les essais et la simulation qui visent à retrouver les défauts les plus probables.

Il fournit des informations de diagnostic dans le cas où une propriété est invalide, ce qui est très
utile pour le débogage.

C‟est une technologie potentielle “Push-button” ; l‟utilisation d‟un model checker ne nécessite
pas un degré élevé d‟interaction entre utilisateurs ou d‟expertise.

Il bénéficie d‟un intérêt de plus en plus prononcé par les industriels : plusieurs sociétés de
matériels ont commencé leurs vérifications internes en laboratoire ; des offres d‟emploi avec les compétences
requises dans la vérification de modèle apparaissent souvent ; et des modèles de vérificateurs commerciaux
deviennent disponibles.

Il peut être facilement intégré dans les cycles de développement existants : sa courbe
d‟apprentissage est relativement rapide, et les études empiriques indiquent qu‟il peut conduire à des temps de
développement plus courts.

Il est basé sur les éléments des algorithmes de la théorie des graphes, les structures de données et
la logique.

Les logiques temporelles peuvent facilement exprimer un grand nombre des propriétés qui sont
nécessaires pour le raisonnement sur les systèmes concurrents.

Si la spécification n'est pas satisfaite, le model checker produira un contre-exemple (trace
d'exécution) qui montre pourquoi la spécification ne tient pas. Les contre-exemples sont très précieux pour le
débogage des systèmes complexes. Certaines personnes utilisent le model checking uniquement pour cette
fonctionnalité.

Dans la pratique, le model checker est rapide en comparaison des autres méthodes rigoureuses
telles que l'utilisation d'un vérificateur de preuves (proof checker), qui peut nécessiter des mois de travail
pour un utilisateur en mode interactif.
43

Le processus de vérification est automatique. L'utilisateur du model checker n'a pas besoin de
construire une preuve de corrections. En principe, l'utilisateur doit entrer une description d‟un circuit ou d'un
programme et la spécification qui doit être vérifiée.

Le model checking peut être utilisé lors de la conception d'un système complexe. L'utilisateur n'a
pas besoin d'attendre la fin de la phase de conception.

Les inconvénients du model checking:

Il est surtout approprié pour le contrôle intensif d’applications et moins adapté pour des
applications ayant des données variant généralement sur des domaines infinis.

Son applicabilité est soumise aux problèmes de décidabilité, pour les systèmes à états infinis, ou
le raisonnement à propos des types de données abstraites (qui nécessite des logiques indécidables ou semi
décidables), alors les algorithmes du model checking ne sont pas, en général, décidables.

Il vérifie le modèle du système, et non le système actuel (produit ou prototype) lui-même, tout
résultat obtenu est donc aussi bon que le modèle du système. Les techniques tellesque les essais sont
nécessaires pour trouver les défauts de fabrication (pour le matériel) ou des erreurs de codage (pour le
logiciel).

Il vérifie seulement l’exigence (besoin) déclarée c'est-à-dire qu’il n’y a aucune garantie
d’exhaustivité (complétude). La validité des propriétés non vérifiées ne peut pas être jugée.

Il souffre du problème de l’explosion combinatoire (explosion d’espace d’états), le nombre
d’états nécessaires pour modéliser le système avec précision peut facilement dépasser la quantité de
mémoire disponible. Malgré le développement de plusieurs méthodes très efficaces pour lutter contre ce
problème, les modèles de systèmes réalistes peuvent encore être trop grands pour tenir en mémoire.

Son utilisation nécessite une certaine expertise dans la recherche d’abstractions appropriées
pour obtenir des modèles de systèmes réduits et aux propriétés de l’état dans la logique du formalisme
utilisé.
III.1.2. Notation Z :
La notation Z a été créée par J.R. Abrial. Est apparu pour la première fois dans un livre, lors
de l'édition en 1980, leur sert à introduire le « modèle relationnel n-aire » de Ted Codd. Une
notation graphique utilise ce modèle relationnel binaire, c'est NIAM (Nijssen Information Analysis
Method), (H. Habrias, Le modèle relationnel binaire, Eyrolles, 1988) développée au sein de Control
Data à Bruxelles.
44
La notation Z est un langage de spécification utilisé pour décrire et modéliser les systèmes
informatiques.

Les avantages de notion Z :

Z comprend une notation de schéma pour aider à la structuration des spécifications

Précise et sans ambiguïté.

La notation est utile d'organiser les pensées et aider la communication des idées sein d'une équipe
de conception.

Existe en boîtes ou schémas. Donc plus faciles à comprendre.

assez lisible pour être utilisé comme un outil de documentation dans un manuel (Clarifier
interfaces internes).

Les Inconvénient de notion Z :

Notation Z est conçu pour être expressif et compréhensible par les humains plutôt que par des
ordinateurs exécutables.

Z ne sont utilisés pour spécifier les aspects fonctionnels des systèmes.

Z n'a pas traité explicitement la gestion des exceptions. [6]
III.1.3. CADP :
CADP (Construction et analyse des processus distribués) est une boîte à outils pour la
conception de protocoles de communication et les systèmes distribués. PCA est développé par
l'équipe CONVECS (anciennement par l'équipe VASY) à l'INRIA Rhône-Alpes et relié à divers
outils complémentaires. PCA est maintenue, régulièrement amélioré et utilisé dans de nombreux
projets industriels.
Le but de la boîte à outils de PCA est de faciliter la conception de systèmes fiables en utilisant
des techniques de description formelle avec des outils logiciels pour la simulation, le
développement rapide d'applications, la vérification et la génération de tests.
PCA peut être appliquée à tout système qui comprend du parallélisme asynchrone, cet est à
dire, tout système dont le comportement peut être modélisé comme un ensemble de processus
parallèles régies par entrelacement sémantique. Par conséquent PCA peut être utilisé pour concevoir
l'architecture matérielle, algorithmes distribués, protocoles de télécommunication, etc. La
vérification énumérative (aussi connu comme la vérification explicite de l'Etat) des techniques
mises en œuvre dans PCA, quoique moins générale que la démonstration de théorèmes, de
45
permettre une détection automatique, le coût-efficace de erreurs de conception dans les systèmes
complexes [7].

les avantages de CADP :

Descriptions de haut niveau écrites en plusieurs langues,

calcul, etc.

La boîte à outils CADP fournit compilateurs (César, CAESAR.ADT, LNT2LOTOS,
FSP2LOTOS, etc.) que de traduire descriptions de haut niveau en code C à être utilisés pour la simulation, la
vérification, et les essais fins;

Descriptions de bas niveau spécifiés comme des automates (ie, machines à états finis) et des
réseaux d'automates communicants qui fonctionnent en parallèle, synchroniser, et de communiquer en
utilisant des opérateurs processus d'algèbre ou vecteurs de synchronisation.

Plusieurs outils de vérification d'équivalence (minimisation et comparaisons modulo bisimulation
relations), comme BCG_MIN et BISIMULATOR.

les inconvénients de CADP :

Manque d'engagement, l'écriture et la description dans une langue, mais dépend de
plusieurs langues
III.1.4. Coq :
Coq est un assistant de preuve utilisant le langage Gallina, développé par l'équipe PI.R2
d'Inria au sein du laboratoire PPS du CNRS et en partenariat avec l'École polytechnique, le CNAM,
l'Université Paris Diderot et l'Université Paris-Sud (et antérieurement l'École normale supérieure de
Lyon).
Le nom du logiciel (initialement CoC) est particulièrement adéquat car : il est français ; il est
fondé sur le calcul des constructions (CoC abrégé en anglais) introduit par Thierry Coquand. Dans
la mêmeveine, son langage est Gallina et Coq possède un wiki dédié, baptisé Cocorico.! [8].

Les avantages de Coq :

Les méthodes de détection d'erreurs.

cadre de Mutation.

La vérification formelle de générateurs.

Approche basée sur les langages.

Les inconvénients de Coq :
46

Les erreurs dans les programmes (définitions), les spécifications (propriétés) et Erreurs
dans les générateurs.
6.
III.1.2. Les approches semis formelles :
7.
III.1.2.1. UML:
Le langage de modélisation unifié, de l'anglais Unified Modeling Language (UML), est
un langage de modélisation graphique à base de pictogrammes conçu pour fournir un méthode
normalisée pour visualiser la conception d'un système. Il est couramment utilisé en développement
logiciel et en conception orientée objet.
Le UML est le résultat de la fusion de précédents langages de modélisation
objet : Booch, OMT, OOSE.
Principalement
issu
des
travaux
de GradyBooch, James
Rumbaugh et Ivar Jacobson, UML est à présent un standard adopté par l'Object Management
Group (OMG) [9].
UML définit beaucoup diagrammes, mais nous proposons les diagrammes très important, il
existe 8 diagramme.
Ceux-ci permettent de visualiser et de manipuler les éléments dits "de
modélisation". Chaque diagramme UML ci-dessous possède une structure précise.

Diagrammes d'activité : représentation du comportement d'une opération en terme d'action

Diagrammes de cas d'utilisation : représentation des fonctions du système du point de vue de
l'utilisateur.

Diagrammes de classes : représentation de la structure statique en terme de classes et de relations.

Diagrammes de collaboration : représentation spatiale des objets, des liens et des interactions.

Diagrammes de déploiement : représentation du déploiement des composants sur les dispositifs
matériels.

Diagrammes d'états-transitions : représentation du comportement d'une classe en terme d'état.

Diagrammes d'objet : représentation des objets et de leurs relations, correspond à un diagramme
de collaboration simplifié, sans représentation des envois de message

Diagrammes de séquence : représentation temporelle des objets et de leurs interactions.

Avantage de l’UML :

Le principal avantage d'UML c'est qu'il est devenu le standard en terme de modélisation
objet, universellement reconnu celui-ci est polyvalent et performant.
47

UML est un langage formel et normalisé, offrant précision et stabilité.

UML est un support de communication performant, permettant de cadrer l‟analyse ; la
compréhension de représentations abstraites complexes est facilitée et son caractère polyvalent et sa
souplesse en font un langage universel.

Inconvénient l’UML :

Son point faible est sans contestation possible, la lourdeur (relative) de sa mise en place
au sein de n'importe quel processus. Son apprentissage assez long et rigoureux peut également être
un frein à son utilisation.

La mise en pratique d‟UML est dangereuse car la modélisation est totalement libre et les
outils sont variés.

UML doit être spécifié pour être utilisé dans un cadre précis sans risque d‟erreur.
II.1.2.2. Réseau de Petri :
Un réseau de Petri (aussi connu comme un réseau de Place/Transition ou réseau de P/T) est
un modèle mathématique servant à représenter divers systèmes (informatiques, industriels…)
travaillant sur des variables discrètes.
Les réseaux de Petri sont apparus en 1962, dans la thèse de doctorat de Carl Adam Petri. Les
réseaux de Petri sont des outils graphiques et mathématiques permettant de modéliser et de verifier
le comportement dynamique des systèmes à événements discrets comme les systèmes
manufacturiers, les systèmes de télécommunications, les réseaux de transport.

Avantages et inconvénients d’un réseau de petri :
L‟analyse de la modélisation Rdp peut identifier, d‟une manière qualitative seulement
(cependant, un niveau de granularité approprié des INPUT est nécessaire), l‟impact et les
conséquences des risques de part et d‟autre des deux infrastructures. Les Rdp peuvent rallier les
composants des deux systèmes TIC et électrique sur le même modèle, avec leur interdépendances.
Pour les systèmes complexes, la robustesse reste à prouver pour les Rdp, il y a notamment un risque
d‟explosion combinatoire et malheureusement aucun outil/plateforme traitant le contexte électrique
n‟a pu être trouvé.
48
IV. Spécification :
Les méthodes formelles peuvent être utilisées pour donner une spécification du système que
l'on souhaite développer, au niveau de détails désiré. Une spécification formelle du système est
basée sur un langage formel dont la sémantique est bien définie (contrairement à une spécification
en langage naturel qui peut donner lieu à différentes interprétations). Cette description formelle du
système peut être utilisée comme référence pendant le développement. De plus, elle peut être
utilisée pour vérifier (formellement) que la réalisation finale du système (décrite dans un langage
informatique dédié) respecte les attentes initiales (notamment en termes de fonctionnalité).
La nécessité des méthodes formelles s'est fait sentir depuis longtemps. Dans le rapport Algol
60, John Backus présentait une notation formelle pour décrire la syntaxe des langages de
programmation (notation appelée Backus-Naur form, BNF). Aujourd'hui, différents moyens
permettent de formaliser la spécification des programmes, on parle alors de sémantique. Il en existe
de différentes natures, chacune adaptée au paradigme de calcul voulu : dénotationnelle,
opérationnelle, axiomatique, par machines à états finis…
V. Développement :
Une fois qu'une spécification a été développée, elle peut être utilisée comme référence
pendant le développement du système concret (mise au point des algorithmes, réalisation en logiciel
et/ou circuit électronique).
Par exemple:

Si la spécification formelle est dotée d'une sémantique opérationnelle, le comportement observé
du système concret peut être comparé avec le comportement de la spécification (qui elle-même doit être
exécutable ou simulable). De plus, une telle spécification peut faire l'objet d'une traduction automatique vers
le langage cible.

Si la spécification formelle est dotée d'une sémantique axiomatique, les préconditions et
postconditions de la spécification peuvent devenir des assertions dans le code exécutable. Ces assertions
peuvent être utilisées pour vérifier le fonctionnement correct du système pendant son exécution (ou
49
simulation), ou mieux encore des méthodes statiques (preuve de théorème, model-checking) peuvent être
utilisées pour vérifier que ces assertions seront satisfaites pour toute exécution du système.
VI. Vérification :
Une spécification peut être utilisée comme base pour prouver des propriétés sur le système.
La spécification est le plus souvent une représentation abstraite (avec moins de détails) du système
en développement: débarrassé de détails encombrants, il est en général plus simple de prouver des
propriétés sur la spécification que directement sur la description complète et concrète du système.
Certaines méthodes, comme la Méthode B, s'appuient sur ce principe: le système est modélisé
à plusieurs niveaux d'abstraction, en partant du plus abstrait et en allant au plus concret (ce
processus est appelé « raffinement » puisqu'il ajoute des détails au fur et à mesure); la méthodologie
assure que toutes les propriétés prouvées sur les modèles abstraits sont conservées sur les modèles
concrets. Cette garantie est apportée par un ensemble de preuves dites «de raffinement ».
VII. Les types des méthodes formelles :
























Approche basée sur des états
Z voir Notation Z
SAZ
Méthode B classique voir Méthode B
ASM
TLA+
Approche basée sur des événements
Action Systems
Méthode B événementielle voir Méthode B
VHDL
Esterel
SDL
LOTOS
E-LOTOS
EB3
Approche basée sur les contrats
Eiffel
Algébriques:
Larch :Larchfamily
CASL : Common AlgebraicSpecificationLanguage
Autre approche
Coq (logiciel)
Réseau de Petri
Algèbre de processus
51
VII. Principaux outils :

ACL2: démonstration de théorèmes automatisée.

AtelierB: spécification et preuve avec la méthode B.

CADP: construction et analyse de processus distribués

Coq: assistant d'aide à la preuve (c'est-à-dire formalisation de preuves et démonstration semi-
automatisée).

Murφ: démonstration de propriétés.

Prototype Verification System: assistant d'aide à la preuve.

SMV, nuSMV: démonstration de propriétés avec BDDs et SAT.

zChaff : démonstration avec SAT.
VIII. Conclusion :
Dans ce chapitre, nous avons étudié les approches formelles et nous devons inclure les
avantages et les inconvénients pour savoir qui est familier avec la façon d'utiliser cette méthode,
afin d'obtenir un programme précis, et sans erreur, et contribuer ainsi à donner l'image exacte et
précise du programme.
Nous abordons dans la section suivante pour un type de programme officiel, une méthode B
une façon formelle de penser à des systèmes complexes et le développement de logiciels, et nous
allons l'étudier étude approfondie de tous les aspects de son histoire dans les zones utilisées pour se
rendre à la table de comparaison entre méthode B et application code Java ….
50
Chapitre III :
L’approche proposée
52
I. Introduction :
ce chapitre
nous présentons méthode B est une méthode de spécification formelle qui
permet, grâce à un langage adéquat, d‟exprimer très rigoureusement les propriétés exigées dans un
cahier des charges. Il est alors possible de prouver de manière automatisée que ces propriétés sont
non ambiguës, cohérentes et non contradictoires. Cela nous permet de garantir ensuite preuve
mathématique que ces propriétés sont respectées au fur et à mesure des étapes de conception.
nous avons étudier notation b et la représentation théorique , La notion de machine abstraite
raffinement , Les étapes de l‟approche en B et en fin nous présentera Tableau de correspondance BJava
II. Historique :
La méthode B à été introduite au milieu des années 80 par J.-R. Abrial. Sans entrer dans les
détails, il est possible de situer B comme une méthode sous-jacente aux méthodes formelles VDM2
et Z3. Cependant, à la différence de ces dernières, B ne se limite pas à la phase de description : elle
permet d'établir une chaîne de production qui va de la spécification du programme au code source
associé.
III .Présentation théorique :
L'objectif initial de B est de fournir une technique et des outils associés capables d'aider la
construction de logiciels de la façon la plus sûre possible. C'est une méthode transformationnelle :
on part d'un modèle abstrait (une machine abstraite) puis on en réduit le niveau d'abstraction, étape
par étape (par des raffinements), jusqu'à l'obtention d'un modèle concret, proche du code source
(l'implémentation).
L'ensemble des composants spécifiant un comportement (du plus abstrait au plus concret) est
appelé module. Un module peut dépendre de plusieurs autres modules, les principes de dépendance
seront vus par la suite .
Il est alors possible, pour un projet (un ensemble de modules) donné, de générer un code
exécutable sécurisé, car totalement prouvé.
53
IV. La méthode B:
IV. 1. Définition :
La méthode B est une méthode de spécification formelle capable de retranscrire de manière
rigoureuse les exigences d‟un cahier des charges, au moyen de preuves mathématiques, afin de
prouver leurs cohérences. Ce procédé permet notamment de lever toute ambiguïté sur les propriétés
initialement exprimées en langage naturel. Le langage B peut être utilisé sur des protocoles comme
sur de l‟informatique embarquée. De plus, la méthode B englobe toute la modélisation par la preuve
d‟un système, de l‟écriture de son modèle à son implantation logicielle, tout en respectant les
données fondamentales d‟origine.
Bien que les usages de la méthode B soient divers (modélisation d‟un système, formalisation de
spécification …), l‟objectif est le même : s‟assurer de la fiabilité, de la sécurité ainsi que de
l‟absence de bugs informatiques d‟un système par des preuves mathématiques.
La méthode B tire sa légitimité du développement d‟outils approuvés et utilisés à grande échelle,
dans le monde industriel comme universitaire, tels que l‟Atelier B. ClearSy est détenteur de ce
dernier et se charge des évolutions et de la maintenance de sa plateforme de développement.
L‟Atelier B constitue ainsi une référence pour le développement de logicielsProuvés.

Les Principes de B:
Il y a 3 ingrédients : modélisation, raffinementet preuve.
Le langage B est basé sur la théorie des ensembleset la logique des prédicats.
54
Figure.IV.1: les principe de B
Il y a Deux applications : système et logicielle
Méthode outillée par
CompoSys et des
outils de atelier B
Méthode outillée
par l'atelier B
Figure.IV.2: Les application de B.
IV.2. Dépendances entre modules :
Un projet B est constitué de différents modules reliés entre eux par des clauses de visibilité,
dont les plus importantes sont présentées au tableau IV.2.
NomDescription
INCLU
composition de plusieurs machines (utilisé dans les machines abstraites et les
DES
raffinements intermédiaires). Une machine ne peut être incluse qu'une seule fois dans
l'ensemble d'un projet.
IMPOR
même principe que la clause INCLUDES, mais pour les implémentations.
TS
USESpartage
de données entre machines (aucun accès aux opérations d'une machine
utilisée).
SEESaccès en lecture seule aux constituants d'une machine (impossibilité d'appeler une
opération de modification).
tableau IV.2. Clauses de visibilité d'un composant B
IV.3. Fondements théoriques :
Nous évoquons dans ce paragraphe les principales notions théoriques utilisées dans la
méthode B.
55
IV.3.1. La théorie des ensembles et les types :
La théorie des ensembles est la base des modèles mathématiques en B. Les relations et les
fonctions (partielles ou totales) sont représentées par des ensembles de couples. Les variables sont
typées par des prédicats (situés dans l'invariant et les pré-conditions), qui expriment une condition
d'appartenance de chaque variable à un ensemble donné.
IV.3.2. Le langage des substitutions généralisées :
Chaque machine abstraite B englobe un état et fournit des opérations permettant d'accéder à
celui-ci ou de le modifier. Les mécanismes qui déterminent ou changent l'état sont
appelées substitutions, et l'ensemble des substitutions utilisables dans le langage B pour décrire les
initialisations et le corps des opérations constitue le langage des substitutions généralisées.
Une substitution modélise ainsi une transaction entre un état pré et un état post, qui correspond,
dans les langages de programmation, à une suite d'instructions non interruptible. Les principales
substitutions sont :

substitution neutre :
SKIP, qui aboutit à un état post identique à l'état pré

substitution simple :
x := E, qui a pour effet d'affecter à la variable x la valeur de l'expression E

substitution multiple :
x, y := E, F, qui exécute en parallèle les substitutions simples x := E et y := F (on peut
également noter x := E || y := F)

substitution devient tel que :
, qui affecte à x une valeur (indéterminée) de l'ensemble S

Les substitutions peuvent ensuite être combinées entre elles au moyen d'opérateurs de
composition (par la suite, P et R désignent des prédicats, G et H des substitutions) :
56

Séquencement :
G ; H,
correspondant
(
à
l'application
successive
des
substitutions G et H
)

substitution pré-conditionnée :
P | G, assurant que la substitution G aboutira à un état post correct si le prédicat P est vérifié à
l'état pré (

)
substitution gardée :
, qui ne peut être appliquée que dans le cas où l'état pré satisfait P (

)
substitution de choix borné :
, qui résulte en l'application de l'une ou l'autre (indéterminisme) des substitutions G ou H (
)

substitution de choix non borné :
@z.G, correspondant à l'application de la substitution G pour une valeur quelconque
(indéterminisme) de la variable z (
, z étant non libre dans R)
V. notation B :
le raffinage :
Raffiner consiste à reformuler les données et opérations d'une machine abstraite à l'aide de
données et opérations plus proches de l'implémentation tout en conservant les propriétés de la
machine abstraite.
-Suppression des pré-conditions
-Suppression de l‟indéterminisme
57
-Introduction de la séquence et des boucles
* Chaque raffinement donne lieu à une preuve de la validité de la reformulation de la machine
abstraite.
* La dernière phase de raffinement permet d'atteindre un niveau de pseudo-code que l'outil
associé, l'atelier B, peut alors traduire automatiquement dans différents langages (C, Ada, C++).
* Le test du logiciel devient inutile, puisque le programme produit est formellement prouvé
correct à la spécification initiale.
V.2.La notion de machine abstraite:

En B

On spécifie

On prouve

On développe

On code
Une (ou plusieurs) machine abstraite

Cette notion est proche de :

Type abstrait, Module, Classe, Composant
La machine abstraite :

Un en-tête (nom )

Des données cachées

Des opérations visibles d‟accès à la machine
Les clauses d’une MA
MACHINE
)Nom de la machine abstraite )idem nom de la classe
SETS
Déclaration des ensembles abstraits et énumérés
VARIABLES
58
Déclaration des variables (idem attributs d‟une classe)
INVARIANT
Typage et propriété des variables
INITIALISATION
)Définition de la valeur initiale des variables (idem constructeur
OPERATIONS
)Déclaration des opérations )idem méthodes
END

L’en-tête :
Un nom + optionnellement des paramètres pour la généricité
MACHINE
calculatrice
END

Les données :
La définition des données s‟appuie sur un langage d‟expressions

les symboles désignant les données de base de la machine (ensembles abstraits,
variables, constantes…)

les expressions booléennes

les expressions arithmétiques

les ensembles, relations, fonctions,

les suites…
Ces données sont caractérisées par un invariant

Une formule de la logique des prédicats exprimée au moyen de prédicats
ensemblistes (appartenance, inclusion…) et de comparateurs arithmétiques.

Les opérations :

Une en-tête (la signature)
liste des paramètres de sortie <-- NOM (liste des paramètres d‟entrée)
59

Une pré-condition

Typage des paramètres d‟entrée

Conditions nominales de fonctionnement de l‟opération (domaine de définition)


Une transformation
Définition de l‟opération comme une transformation des données internes et une
affectation de valeur aux paramètres de sortie

Les transformations:

La définition des opérations s‟appuie sur le langage des substitution généralisées

La transformation de base est la substitution simple devient égal, notée :=

Les autres transformations permettent de modéliser le résultat de tous les
changements d‟états réalisables par algorithmique

Les boucles en particulier sont souvent modélisée par des substitutions indéterministes.


Preuve de cohérence :
La dernière étape de la spécification consiste à prouver la cohérence de chaque machine
abstraite



On prouve pour chaque opération que
lorsque la machine est dans un état correct
Les propriétés invariantes I sont supposées vérifiées

lorsque l‟opération est appelée dans des conditions nominales

la pré-condition P d‟appel est supposée vérifiée

alors sa transformation S amène la machine dans un état correct

un état qui satisfait l‟invariant I
- Deux étapes de preuve :


Calcul de [S]I la plus faible pré-condition
Condition minimale garantissant que l‟état de la machine après l‟opération respecte
l‟invariant


On applique simplement la substitution S à la formule I
On prouve que les conditions initiales (invariant et pré-condition) impliquent cette plus faible pré-
condition

Pour chaque opération, la formule dont il faut établir la validité est donc de la forme
I  P  [S]
61
V.3. Les étapes de l’approche en B :
Parmi les caractéristiques de B , nous citons la preuve qu 'elle nous apporte dans la
spécification d'un système. En fait à quoi revient à faire une démonstration de preuve en B, et quel
intérêt nous apportet-elle? Ce qui est démontré dans une preuve d'une MA c'est que les pré
conditions citées dans ses opérations doivent préserver l'invariant de la machine qui est en fait la
conjonction de l'ensemble des variables nécessaires dans le système à développer (propriétés
souhaités du système ); lors de la définition des opérations il ne faut en aucun donner un prédicat
qui contredit l 'invariant de la MA, ce qui peut se déduire de cela : l'échec d'une preuve alors que le
modèle B (fig V.3) est cohérent montre la non faisabilité d'une partie du cahier des charges et ce
très tôt dans le cycle de vie du système .La démonstration de preuve d'un système formalisé avec B
permet d'établir la cohérence totale du cahier des charges. Dans la figure ci-dessous nous
schématisons la modélisation d‟un système d‟information durant tout son cycle de vie par B
[MH.98].
Figure .IV.3. Modèle en B.
V.3.1.formalisation :
les besoins sont réécrits dans un formalisme mathématique plus ou moins formel .
V.3.2.approbation :
En cas de conflit avec l'utilisateur sur des données ou des traitements, il est recommandé de
revoir le cahier des charges.
V.3.3.structuration :
L'analyse du système permettra sa structuration en sous-systèmes clairs et analysables appelés en
B par machine abstraite(élément de base d'une modélisation B).
60
V.3.4.traçabilité :
Les propriétés logiques présentes dans l'analyse du système et dans le modèle B doivent être
littéralement identiques.
V.3.5.développement B :
Au fur et à mesure que les raffinages successifs s'effectuent sur le modèle abstrait
(développement B ) nous constatons la
constitution progressive d'un code de programme
exécutable du système à développer.
La démonstration de preuve dans la phase de raffinage assure dans un sens le respect du modèle
abstrait jusqu‟à l‟implantation finale du système.
Figure .IV.4. La preuve
Dans le cas d‟échec de la preuve (Figure.V.3.5) ,ce qui revient à ce que un prédicats cité
dans une des opérations de la MA ne préserve pas son invariant ,il faut donc revoir la
spécification des opérations. Une autre possibilité, dans le cas où le modèle B est tout à fait correct
donc ce qu„il faut revoir c‟est le cahier des charges qui aurait dû être mal rédigé .

B en pratique:

On définit les données internes de la machine et leurs propriétés invariantes ;

On définit les opérations d‟accès à la machine : pré-condition et transformation ;

L‟atelier vérifie la syntaxe et le typage ;

L‟atelier calcule les plus faibles pré-conditions et génère les preuves à faire ;

L‟atelier tente de les prouver automatiquement ;

Si certaines preuves n‟ont pas été démontrées, on détermine si :
62
1.
l‟opération est incorrecte et on corrige
2.
le prouveur n‟est pas assez « fort » et on aide le prouveur à
VI. Le langage de modélisation :
Expression de variables, constantes, opérations, invariants, théorèmes, · · ·
1. Théorie des ensembles :

SIEGES = 1..nb_max

occupes ⊆ SIEGES
2. Fonctions, relations :

etat∈ SIEGES → BOOL

etat−1fonction réciproque.
3. Logique des prédicats :

occupes = etat−1[{TRUE }]

x ∈ 1..1280 ∧ y ∈ 1..1024
Des opérations sont définies pour manipuler et construire des
ensembles, relations, fonctions, et prédicats
4.Substitutions généralisées :
Elles permettent de décrire les changements d‟état

La développement d'un systèmes :
63
Figure.IV . 5 . Développement B d'un systèmes informatiques
V. Extraction d’un modèle B-évent :

Objectif : projeter l‟aspect comportemental du système interactif en un modèle B-évent.
Représenter l‟exécution des méthodes de listeners comme un ensemble de processus séquentiels
composés d‟affectations...

Solutions :
1.
Retro-concevoir la BAO Swing (B Swing).
2.
Annoter le code source.
3.
Utiliser un modèle intermédiaire : In-lining, abstraction...
4.
Traduire le modèle intermédiaire en B-évent en important le modèle B Swing.
Figure V.5: Méthode d‟extraction d‟un modéle B-évent.
64
IV. Les règles de traductions :
La traduction (descendant/ascendant) en B nécessite des règles de traduction pour représenter ces
structures de contrôle.
IV.1. La traduction descendante (UML-B) :
Capturer l‟aspect comportemental (diagrammes d‟activités) des processus de l‟application.
Puis représenter l‟exécution des activités de l‟application
comme un ensemble de processus
(séquentiels ou parallèles composés d‟affectations) en B. Ces affectations sont ordonnancées par un
ensemble de structures de contrôle : composition séquentielle, boucles, if then else…
IV.2. La traduction ascendante (JAVA-B) :
Capturer l‟aspect comportemental de code source (JAVA) .Puis représenter l‟exécution des
ces instructions comme un ensemble de processus : séquentiels ou parallèles composés
d‟affectations en B.
Figure.V.2. La traduction ascendante (JAVA-B).
IV.3. Les règles de codage (B-JAVA) :
65
Les spécifications abstraites (B), sont raffinées jusqu‟à l'obtention du niveau d'abstraction (en
langage B) correspondant à la formalisation des concepts du code source JAVA. Ce niveau
d‟abstraction a été défini comme un ensemble d‟affectations. Ces affectations sont ordonnancées
par un ensemble de structures de contrôle en JAVA : composition séquentielle, boucles, if then
else…
Figure.V.3. Les règles de codage (B-JAVA).
IV.4. Tableau de correspondance B-Java :
Le tableau qui suit présente quelques fonction en java est transformée en méthode B.
Fonction
Structures if
Appels
d’opération en B
Utilisation de
l’ELSIF
Java
if (expr)
{
bloc1else bloc2
x = Math.sqrt(Math.abs(y));
if (expr1s)
{
bloc1elseif (expr2s) bloc2
...else if (exprns) blocnelseblocd
}
Méthode B
IF expr THEN bloc1
ELSE bloc2 END
VAR tmp IN
tmp←abs(y) ; x ← sqrt(tmp1)
END
IF expr1s THEN bloc1
ELSEIF expr2
s THEN bloc2
...
ELSEIF exprns THEN blocn
66
ELSE blocd
END
switch (expr)
CASE expr OF
Structures
{
EITHER c1 THEN bloc1
switch
case c1:
OR c2 THEN bloc2
bloc1break = new . . .
bloc1();
OR cnTHEN blocn
case c2:
ELSE blocd
bloc2break = new bloc2(); END
...S
case cn:blocnbreak;
default:
blocdbreak}
WHILE expr
Structures whilewhile (expr)
{
DO bloc
Bloc
INVARIANT expri
VARIANT exprv
END
VAR first IN
Structures do do
{
first := TRUE ;
bloc while (expr)
WHILE first = TRUE ˅expr
DO first := FALSE ; bloc
INVARIANT expri
VARIANT exprv
END
END
1
2
bloc1 ;
Structures for for (bloc ;expr;bloc )
{
WHILE expr
3
bloc
DO bloc3 ; bloc2
INVARIANT expri
VARIANT exprv
END
SETS IDSINT = {x, y}
Modélisation de int x = 0;
VARIABLES valsint
variables entières) int y;
INVARIANT valsintϵ IDSINT →SINT
INITIALISATION valsint := {x →0};
OPERATIONS
Wsint(i, v)
PRE I ϵ IDSINT ˄ v ϵ SINT
THEN valsint(i) := v END ;
out ←Rsint(i)
PRE i ϵdom (valsint)
THEN out := valsint(i) END
67
publicclassGlobalMembers
{
publicstaticcpl c1 =
newcpl();
publicstaticcpl c2 =
newcpl();
}
publicclasscpl
{
publicint x;
publicbyte y;
}
x = Math.sqrt(3 * x);
Traduction
d’une expression)
Structures et
fonctions de
valuations)
public classP_converter
Validation
formelle de Java / implements ActionListener {
private JButton XY,YX;
Swing, des
private JTextField output;
interfaces
utilisateur avec le Bpublic P_converter(){
…
Méthode
output=new JTextField();
événement
XY= new JButton(“X>Y”);
FE=new JButton(“Y->X”);
XY.addActionListener(this);
YX.addACtiolistener(this);
XY.setEnabled(false);
YX.setEnabled(false); }
…
public void
actionPerformed(ActionEvent
e)
{ output.setVisible(true);
if(e.getSource()==XY){
XY.setEnabled(false);
YX.setEnabled(true);
result=convert(input.getText()
,true);
ouput.setText(result);}
else {
XY.setEnabled(false);
YX.setEnabled(true);
result=convert(input.getText()
,true);
SETS IDCPL = {c1, c2}
VARIABLES valcplx, valcply
INVARIANT valcplx ϵ IDPOINT → SINT ˄
valcply ϵ IDPOINT→ SCHAR
INITIALISATION valcplx = ɸ; valcply = ɸ
VAR tmp IN
tmpmul(3, x_L) ; x_Lsqrt_G(tmp)
END
INITIALISATION
widgets := {YX,XY,output…} ||
listeners := {list1,…} ||
W_att:={output → (false,false, ɸ)
XY → (false,false,{list1})
YX → (false,false,{list1}) …} ||
UA :∈struct(source ∈ widgets,…) ||
V_aP := 1 || ...
EVENTS
Action_Performed_list1_1=
SELECT
V_aP=0 ∧UA‟source=XY∧
list1 ∈w_att(UA‟source)‟lists ∧
L_att(list1)‟id=ActionListener∧
UA‟typ=ActionPerformed
THEN
V_aP := 0 ||
W_att(output)‟visible := true ||
W_att(FE)‟enabled := false ||
W_att(EF)‟enabled := true ||
Jtf_att(output)‟value := result
END;
ActionPerformed_list1_2=
SELECT
V_aP=1 ∧ not(UA‟source=XY) ∧
list1 ∈ W_att(Au‟source)‟lists ∧
L_att(list1)‟id=ActionListener∧
UA‟typ=ActionPerformed
THEN
V_aP := 0 ||
68
W_att(output)‟visible := true ||
W_att(EF)‟enabled := false ||
W_att(FE)‟enabled := true ||
Jtf_att(output)‟value := result
END;
Tab.1.comparation entre java et méthode B.
ouput.setText(result);}
}
}
VII. Conclusion :
Nous avons analysé dans cette section la méthode b afin d‟appliquer ces caractéristiques
pour la vérification et la validation d‟une application Java, et afin de capturer avec précision les
spécifications des exigences, en utilisant évidence mathématique pour prouver la cohérence de leur
propre et nous devons donner table de comparaison entre méthode B et le code Java .
Dans le chapitre suivant, nous allons donner une idée claire sur la conversion et un exemple
d'une application Java à Méthode b et déboguer le programme.
69
Chapitre IV :
Etude de cas et Implémentation
71
I. introduction:
Notre approche pour vérifier un programme écrit en Java a été présentée en détails au cours
du chapitre précédent. Pour illustrer les différentes idées et concepts inclus dans notre proposition
nous allons présenter un exemple sous la forme d‟une étude de cas. Nous allons choisir la
réservation de voyages en ligne comme un domaine d‟application.
II. Outils B:
Ce partie a pour but de présenter les différentes fonctionnalités offertes par l'Atelier B.
L'Atelier B est un ensemble d'outils logiciels permettant le développement d'applications suivant
la méthode B. [CS.01]
L'Atelier B assiste le concepteur dans la formalisation de son application:
nombre d'actions dictées par la méthode,
des développements industriels, comme la gestion, l'analyse et la documentation d'un
projet.
II.1. Objets manipulés par l'Atelier B :
Nous introduisons dans ce paragraphe les principaux objets manipulés par les fonctions de
l'Atelier B.
Composant : Fichier contenant un source écrit en langage B. Il constitue la base d'un
développement suivant la méthode B. Un composant est un terme générique et représente :
ation B (machine abstraite),
II. Environnement de travail :
L‟Atelier B est l‟outil industriel qui permet une utilisation opérationnelle de la méthode
formelle B pour des développements de logiciels prouvés sans défaut (logiciel formel). Il est
disponible en deux versions: une version communautaire accessible à tous sans limitation, une
version maintenue accessible aux possesseurs d‟un contrat de maintenance.
Il est utilisé pour le développement des automatismes sécuritaires des différents métros
développés dans le monde par Alstom et Siemens et d‟autres part, pour la certification selon la
70
norme « Critères Communs » et le développement de modèles systèmes par ATMEL et
STMicroelectronics.
Il a par ailleurs été utilisé sur plusieurs autres secteurs comme celui de l‟automobile pour la
modélisation des principes de fonctionnement de l‟électronique embarquée de 3 modèles de voiture.
L‟Atelier B est aussi utilisé dans le secteur de l‟aéronautique et de l‟aérospatial.

Il existe deux ateliers de génie logiciel qui permettent la mise en oeuvre de la
méthode B dans des projets industriels : l'AtelierB, diffusé par la société française ClearSy, et le BToolkit de la société britannique B-Core. Tous deux disposent d'outils pour :

l'analyse lexicale des composants

le contrôle de types

la génération d'obligations de preuve

la démonstration automatique des propriétés

la démonstration interactive des propriétés

la traduction en langages de programmation impératifs (C, C++ ou ADA)

la gestion et la documentation des projets
Figure V.1: méthode B dans l'environnement d'Atelier B.
72
III.1. Objets manipulés par l'Atelier B :
Nous introduisons dans ce paragraphe les principaux objets manipulés par les fonctions de
l'Atelier B.
Composant : Fichier contenant un source écrit en langage B. Il constitue la base d'un
développement suivant la méthode B. Un composant est un terme générique et représente :
_ soit une spécification B (machine abstraite),
_ soit un raffinement de cette spécification,
_ soit son implémentation (dernier niveau de raffinement).
La saisie des composants est réalisée gâce à l'éditeur de texte de la station de développement.
Projet : Ensemble de fichiers (composants, fichiers annexes sources C, C++, HIA, ou
ADA, makefiles) utilisés ou produits durant le développement d'une application suivant
la méthode B, complété des informations nécessaires à la gestion de ces _chiers sous
l'Atelier (voir BDP).
Utilisateur : Il est nécessaire de dé_nir une liste d'utilisateurs autorisés à accéder et modi_er le projet. Notez que tous les utilisateurs ont les mêmes pouvoirs, et qu'il est nécessaire
qu'au moins un utilisateur soit renseigné.
Base de Données Projet (BDP) : Toutes les informations internes nécessaires à la bonne
exécution des outils de l'Atelier B sont stockés dans un répertoire nommé BDP. Ce répertoire
contient aussi des fichiers produits par les outils de documentation de l'Atelier B.
III.2. Modes d'utilisation de l'Atelier B
Nous appelons Outils B les outils liés à l'application de la méthode B, ainsi qu'à l'analyse, la
mise au point et la documentation de logiciels écrits en B. L'environnement B , propose deux modes
d'utilisation des outils B :

Un mode interactif, utilisant une interface graphique à base de fenêtres et de boutons
de commande ; dans la suite du document nous appellerons ce mode interface utilisateur
graphique,

Un mode programmé, reposant sur un langage appelé langage de commande;
dans la suite de ce document, nous appellerons cette interface interface utilisateur mode
commande.
73
III.3. Présentation générale :
A) Interfaces
L'interface graphique de l'Atelier B se décompose en deux parties majeures : l'une est dédiée à la
gestion des projets B, et l'autre permet une édition aisée via un éditeur spécialement conçu pour
assister l'utilisateur dans son développement B.
Nous aborderons par la suite les détails de l'utilisation de ces dernières.

IHM principale :
L'interface principale se présente de la façon suivante :
Figure :
C'est à partir de cette interface que la majeure partie de la gestion des projets B s'effectue.

Éditeur intégré :
74
L'Atelier B est livré avec un éditeur spéci_quement adapté à l'édition de composants B. Celui-ci
propose des fonctionnalités comme l'auto-complétion de mots-clé, le soulignement en cas d'erreur,
etc.
Un aperçu de la fenêtre est donné ci-dessous :
Figure :

Une navigation par onglets entre les fichiers.

Il inclut en outre un tableau permettant l'insertion aisée des symboles B.

Ce dernier s'utilise comme un éditeur de texte classique et a été conçu de façon à rendre
son utilisation intuitive.
III.4 : Pour démarrer :
Cette paragraphe décrit plus particulièrement la démarche générale permettant d'utiliser les
fonctions de l'Atelier B.
→
En résumé, afin de démarrer un développement avec l'Atelier B, vous devez :
75
1. Créer un projet,
2. Ouvrir ce projet,
3. Ajouter des composants à ce projet.
Ou plus simplement, si vous disposez d'une archive de projet, vous pouvez restaurer cette
dernière et commencer à travailler.
→
Une fois ces étapes accomplies vous pouvez commencer à appliquer la méthode B sur
vos composants ; il est possible de :
1. Effectuer l'analyse syntaxique et le contrôle de types,
2. Générer les obligations de preuve,
3. Démontrer automatiquement une partie de ces obligations de preuve,
4. Afficher les obligations de preuve,
5. Utiliser le prouveur interactif pour démontrer les obligations de preuve restantes
→
Après avoir créé les implémentations de votre projet, vous serez en mesure de :
1. Contrôler le langage des implémentations,
2. Traduire le projet en langage cible en utilisant un traducteur.
→
Lors de ces phases du développement, utilisez les fonctions d'analyse de l'Atelier B, pour
:
1. Afficher l'état d'avancement du projet ou d'un composant,
2. Afficher des graphes de dépendances entre les composants,
Vous pouvez également utiliser des fonctions de documentation pour produire automatiquement
des documentations au format des traitements de texte LATEX, PDF, ou RTF.
→
Lorsque vos projets atteignent une taille importante, vous pouvez :
1. Les archiver pour en faire des sauvegardes,
2. découper vos gros projets en plusieurs petits projets en utilisant la notion de bibliothèques.
IV. Présentation de notre exemple:
Une agence de voyages (service01) fournit les trois services suivants : réservation de billets
d‟avion (service02), réservation de chambres d‟hôtel (service03) et de location de voiture
(service04). Afin de fournir ces services à ses clients, l‟agence doit établir des liens avec d‟autres
services : compagnies aériennes, des hôtels, des compagnies de location de voiture et des banques
76
(service05) pour faciliter les transactions financières entre les clients et l‟agence de voyages et entre
l‟agence et les autres partenaires. A cet effet cinq services web peuvent être proposés :

WS-AV: fournit une interface avec le client, et établir des liens avec les autres services,

WS-VOL : permet de réserver les vols selon une date précisée, la ville de départ et
d‟arrivée et le nombre de personnes.

WS-Hotel : permet de réserver les chambres d‟hôtel selon la date et la ville précisé
et le nombre de personnes.
WS-LV : permet de réserver les voitures selon une date précisée et les nombres de jours.
WS-Bank : permet à l‟agence et les clients de payer les différentes réservations.
La figure suivante présente les services de notre exemple :
Figure V.2: interface d‟agence de voyageAlors…
77
Figure IV.3 : plan simplifier de système.
Dans cet exemple le service (WS-AV) est la composition de quatre services (WS-VOL,
WS-Hôtel, WS-LV et WS-Bank).
Donc le service WS-AV a comme rôle d‟organiser le voyage par internet. Le service fournit aux
clients une interface pour saisie les informations suivantes:
Date de départ, date de retour, ville départ, ville arrivé et nombre de personnes et retournera les
billets et le prix total de voyage .
Le scénario interne qui dirigera les interactions entre les services est le suivant : Le service WSAV va d‟abord connecter à la fois les services WS-Hôtel et WS-VOL à travers ses méthodes
respectivement reserveCHam() et reserveVol().En suite et après assurer les réservations présédents,
elle va connecter au service WS-LV par la méthode reserveVoiture().En fin elle va envoyer le prix
de chaque service au service WS-Bank pour calculer le prix total et payer par sa méthode payer( )
comme le montre le diagramme d‟activité UML suivant.
78
Figure IV.4: le diagramme d‟activité UML.

Java-Swing program:
public class ChoixTransport
extends JFrame
implements ActionListener, KeyListener
private JTextField input,output ;
JButton WS-ALR,WS-TR ;
DC ChoixTransport dc ;
public P ChoixTransport()
{ Initialize() ;
subscribe() ;}
public void Initialize(){
/*Widgets creation*/
input=new JTextField() ;
output=new JTextField() ;
WS-ALR= new
79
JButton("AIRLINE RESERVATION") ;
WS-TR=new
JButton("TRAIN RESERVATION") ;
/* Widgets initialization */
WS-ALR.setEnabled(false) ;
WS-TR.setEnabled(false) ;
output.setEnabled(false) ;
this.setVisible(true) ;}
/*listeners subscriexion*/
public void subscribe() {
input.addKeyListener(this) ;
WS-ALR.addActionListener(this) ;
WS-TR.addActionListener(this) ;} ;
public void desactivateEF(boolean b){
WS-ALR.setEnabled( !b) ;
WS-TR.setEnabled(b) ;}
/* Accessor and modifior */
public String getInput()
{return input.getText() ;}
public void setOutput(String s)
{output.setText(s) ;}
/* Listener methods */
public void actionPerformed(ActionEvent e)
{if (e.getSource()==WS-ALR)
controler.WS-ALRConvert(true) ;
if (e.getSource()==WS-TR)
{dc.WS-TRConvert(false) ;}
81
public void keyPressed(KeyEvent e){}
public void keyReleased(KeyEvent e){}
public void keyTyped(KeyEvent e){} }
Java-Swing program en méthode B :
DEFINITIONS
Strings == {no_text, value } ;
JTextField input,output ;
JButton WS-ALR, WS-TR ;
Listener lis1;
INITIALISATION
lis1.typs : ActionListener, KeyListener ;
input.visible = true ;
input.enabled = true ;
input.addKeyListener =(lis1);
output.visible = false ;
output.enabled = false ;
WS-ALR.text=" WS-ALR -> WS-TR " ;
WS-TR.text=" WS-TR -> WS-ALR " ;
WS-TR.addActionListener =(lis1) ;
WS-ALR.enabled = false;
WS-TR.enabled = false ;
WS-ALR.addActionListener =(lis1)
//OPERATIONS
EVENTS
Evt_ActionPerformed_lis1 =
SELECT UserAction'source ∈ { WS-TR, WS-ALR }∧
widgets_att(UserAction'source)'enabled = TRUE ∧
widgets_att(UserAction'source)'visible = TRUE ∧
UserAction'list=lis1 ∧ UserAction'typ=ActionEvent ∧
∧ EVStart=1
THEN
Jtextfields att(output) 0text := Text k widgets att(output)
0visible := true k
EVStart := EVStart-1
END ;
Evt ActionPerformed list1 1 =
SELECT
EVStart= 0 ∧ UserAction'source= WS-ALR
THEN
widgets att(WS-TR) 0enabled := true k widgets att(WS-ALR) 0enabled
:= false
END
Evt ActionPerformed list1 2 =
SELECT
80
EVStart= 0 ∧ not(UserAction’source= WS-ALR)
THEN
widgets att(WS-TR) 0enabled := false k widgets att(WS-ALR)
0enabled := true
END
Bibliothèque :
MACHINE
b_swing
/* transport
* Author: aci
* Creation date: 25/05/2015
*/
SETS
/* Abstrait Sets */
STRINGS = {Text,No_Text } ;
LISTENERS ; LISTENERS_typ = {ActionListener, KeyListener} ;
EVENTS_id = {ActionPerformed, KeyPressed, KeyReleased } ;
EVENTS_typ = {ActionEvent, KeyEvent } ;
WIDGETS
ABSTRACT_VARIABLES
/* Sets to describe application Instances */
widgets, JButtons ,JTextFields, listeners,
/* Total Functions to describe Attributes of instances*/
w_att, JB_att,JTF_att,l_att,
/* Event Buffer : representation of JVM events */
User_Action, method_of , typ, idd ,set1 ,set2
INVARIANT
/* Typing Predicates */
widgets ⊆ WIDGETS ∧
JButtons ⊆ WIDGETS ∧
JTextFields ⊆ WIDGETS ∧
listeners ⊆ WIDGETS∧
//...
w_att ∈ widgets → struct(visible :BOOL, enabled :BOOL,
lists:ℙ(listeners))∧
JB_att ∈ JButtons → struct(text :STRINGS /*/...*/) ∧
JTF_att ∈ JTextFields → struct(text :STRINGS/*...*/) ∧
l_att ∈ listeners → struct(typs : ℙ (LISTENERS_typ))∧
User_Action ∈ struct(typ :EVENTS_typ, idd : EVENTS_id,
:widgets)∧
source
/* consistence invarants */
widgets = JButtons ∪ JTextFields∪ listeners ∧
∀ (set1 , set2 , set3).(set1 ⊆ JButtons ∧ set2 ⊆ JTextFields ∧ set3
⊆ listeners ⇒ set1 ∩set2 ∩ set3 = ∅)
END
En Pratique :
82
Figure IV.6: interface agence de voyage.
Figure IV.7: code machine b_swing.
Après…
83
Figure IV.8: vérification de type et raffinement.
Figure IV.9: opération le preuve.
84
Figure IV.10: fin l'opération le preuve.
Figure IV.11: table classique d'un composant .
V . Conclusion :
Dans ce chapitre, Nous avons proposé une étude, pour bien illustrer l'approche proposée
dans les chapitre IV et pour éclaircir la possibilité d‟intégrer ce type des systèmes complexes dans
le cadre de la méthode formelle B.
85
Conclusion générale
86
C
et mémoire décrit une approche formelle de développement d‟applications java .
Cette approche est basée principalement sur la technique de raffinement B. Le
processus de raffinement décrit dans ce papier est dédié à la génération d‟une
implémentation relationnelle à partir de spécifications formelles B qui traduisent
les données et fonctionnalités d‟une application java . Nous avons défini un ensemble de règles qui
permet non seulement le raffinement des données mais aussi des opérations associées. En utilisant
le prouveur de l‟AtelierB (version 4.2.1), l‟ensemble des règles définies dans ce processus a été
prouvé , donnant lieu à des scénarios de preuves génériques et donc réutilisables par instanciation.
L‟approche présentée dans cet mémoire présente plusieurs avantages
• réduction du coût de développement : automatisation des phases de spécification et de
raffinement
• normalisation du code généré : les deux phases de traduction et de raffinement sont dictées par
des règles précises et déterministes. Cette normalisation de code offrira une meilleure
compréhension et maintenance du code ainsi produit .
Nos travaux actuels portent sur la réalisation d‟un outil de raffinement automatique. Cet outil
viendra compléter l‟outil, , permettant la traduction quasi automatique des application java en
spécifications B. L‟outil complet, ainsi obtenu, aura pour but d‟assister le concepteur durant le
processus de développement de ses applications. Un tel outil déchargera le concepteur des
différentes phases manuelles et surtout coûteuses du processus de développement d‟une application
java. Nous travaillons aussi sur le processus de réutilisation des différentes preuves élémentaires
(chaque preuve élémentaire est associée à une règle de raffinement) lors de l‟établissement de
preuves plus complexes associées à la composition de plusieurs règles de base
Nos propositions ouvrent plusieurs perspectives scientifiques à court et à plus long terme.
Nous soulignons ici certaines de ces perspectives:
- La réalisation d‟un outil de traduction automatique. Cet outil viendra compléter cet outil,
permettant la traduction automatique des diagrammes UML et en spécifications B.
- Nous travaillons aussi sur les mêmes idées afin de les appliquer sur l‟autre aspect
technologique des applications Web qu‟est BPEL4SW.
87
Bibliographie
Bibliographie
[MD.14]:
Jean Michel DOUDOUX : Développons en Java v 2.00 Copyright (C) 1999-2014 Jean-M
ichel DOUDOUX
[GL.94] :
Maintenance ATELIER B Europarc de PICHAURY CLEARSY 0331 Av. J.R. Guilibert
Gauthier de la Lauziere - Bat C2 03831Aix-en-Provence Cedex 3 France.1994
[MG.12]:
Mahdi Gueffaz. ScaleSem : Model Checking et Web S´emantique. Symbolic Computation.
Université de Bourgogne, 2012. French.
[AC.98]:
Alexandre Cortier ONERA - Office National d‟´etude et de Recherche A spatiales 1998.
88
Webographie
[web.02]
http://www.dicofr.com/cgi-bin/n.pl/dicofr/definition/20010101002329
[web.01]
http://rmdiscala.developpez.com/cours/LesChapitres.html/Java/Cours1/Chap1.2.htm
[web.3]
http://home.gna.org/brillant/2004-Moniot/B-mf.html
[web.4]
http://fr.wikipedia.org/wiki/Model_checking
[web.5] http://www.scribd.com/doc/241156624/Advantage-and-Disadvantage-of-zLanguage#scribd
[web.6]
http://www.inrialpes.fr/vasy/cadp/
89
Glossaire
ANSI : Agence Nationale De Sécurité Informatique
API :
Application Programming Interface
CADP: Construction et Analyse De Processus Distribués
CASL : Common Algebraic Specification Language
JCA :
Java Cryptography Architecture
JCE :
Java Cryptography Extension
JDK :
Java Development Kit
JFC :
Java Foundation Classes
RDP:
Réseau De Petri.
JVM :
Java Virtual Machine
J2ME : Java Micro Edition
J2RE : Java 2 Runtime Environnent
J2SDK : Java 2 Software Développent Kit
J2SE : Java Standard Edition
MA :
Machine Abstraite
OMG : L'Object Management Group
RDP:
Réseau De Petri.
UML: Unified Modeling Language
JNDI (Java Naming and Directory Interface) :
JMX (Java Management Extensions) :
JSTL (Java server page Standard Tag Library)
91
90