CR-Méthodes Formelles

DocuSign Envelope ID: F90469B8-B4C2-466A-B666-3ABF970171D5
Institut Supérieur d'Informatique et de Mathématiques de

Monastir (ISIMM)
Architecture de Logiciel et
Méthodes Formelles
Dr Imed ABBASSI
Enseignant chercheur à ISIMM
ENIT, LR-OASIS, Université de Tunis El Manar, Tunis
imed.abbassi@enit.utm.tn
A propos du cours
Objectifs:
• Apprendre les concepts fondamentaux d’architecture
logicielle
• Apprendre le langage logico-ensembliste
• Apprendre les méthodes formelles B et Event-B
Références :
• Jean-Raymond Abrial. Modeling in Event-B: system and
software engineering. Cambridge University Press, 2010.
• BASS, Len, CLEMENTS, Paul, et KAZMAN, Rick. Software
architecture in practice. Addison-Wesley Professional, 2003.
2
Plan du cours
I. Les concepts de base d’architecture

logicielle
II. La méthode formelle B
III. La méthode formelle Event-B
3
Chapitre 1: concepts de base

d’architecture logicielle
4
Plan du chapitre
1. Introduction
2. Modélisation avec UML
3. Éléments architecturaux
4. Choix d’une architecture
5. Vérification d’une architecture
5
Introduction (1)
• L’architecture d’un logiciel décrit la structure des modules

d’un système informatique.
• Cette structure inclut les éléments suivants:
– Les composants logiciels
– Les propriétés externes visibles de ces composants
– Les relations entre ces composants.
• La définition d’une architecture logicielle consiste à:
– Décrire l’organisation générale d’un système et sa décomposition
en des sous-systèmes (les composants).
– Déterminer les interfaces entre les composants.
– Décrire les interactions et le flot de contrôle entre les composants.
– Décrire également les composants utilisés pour implanter les
fonctionnalités des composants.
6
Introduction (2)
Avantages d’une architecture logicielle:

• Compréhension: facilite la compréhension des grands
systèmes complexes en donnant une vue de haut-niveau
de leur structure et de leurs contraintes.
• Réutilisation: favorise l’identification des éléments
réutilisables, parties de conception, composants,
caractéristiques, fonctions ou données communes
• Construction: fournit un plan de haut-niveau du
développement et de l’intégration des modules en mettant
en évidence les composants, les interactions et les
dépendances
7
Introduction (3)
• Évolution: met en évidence les points où un système peut

être modifié et étendu.
• Analyse: offre une base pour l’analyse plus approfondie de
la conception du logiciel.
– Analyse de la cohérence
– Test de conformité
– Analyse des dépendances
• Gestion: permet d’identifier où les délais peuvent survenir
et leur impact sur la planification générale du projet.
8
Introduction (4)
• La conception architecturale est une étape primordiale

dans le cycle de développement de logiciels.
• Une architecture faible ou absente peut entraîner de graves

problèmes lors de la maintenance du logiciel.
9
Modélisation avec UML (1)
• En UML, l'architecture d'une application logicielle est

décrite selon trois vues:
– Vue logique: Description logique du système décomposé en sous-
systèmes (modules + interface)
• UML : diagramme de paquetages
– Vue d’implémentation: Description de l’implémentation du
système logiciel en termes de composants et de connecteurs.
• UML : diagramme de composants
– Vue de déploiement: Description de l’intégration et de la
distribution de la partie logicielle sur la partie matérielle
• UML: diagramme combiné de composants et de déploiement
10
• Un programme peut être structuré en trois vues

complémentaires de la manière suivante:
Vue structurelle (modèle statique) Niveau 1

• Diagramme combiné de déploiement/composants
• Diagramme de classes
• Diagramme de composants
• Diagramme de packages
Niveau 2
Vue des cas d’utilisation (modèle fonctionnel des exigences)
• Diagramme de cas d’utilisation
Vue du comportement et des interactions (modèle dynamique) Niveau 3

Diagramme de séquence: Interaction
Diagramme d’états: comportement
Diagramme de communication: Interaction
Diagramme d’activités: Comportement
11
Diagramme de paquetages
• Les packages sont des espaces de noms :
– deux éléments ne peuvent pas porter le même nom au sein du
même package.
– Par contre, deux éléments appartenant à des packages différents
peuvent porter le même nom.
• La structuration d’un modèle en packages est une activité
délicate.
• Elle doit s’appuyer sur deux principes fondamentaux :
– Cohérence: regrouper les classes qui sont proches d’un point de
vue sémantique.
– Indépendance: minimiser les relations entre les classes des
différentes packages.
12
• Exemple de packages contenant des classes
13
Diagramme de composants
• Ce diagramme représente la structure du système logiciel,

qui décrit les composants du logiciel, leurs interfaces et
leurs dépendances.
• Ce type de diagramme prend en charge le développement
à base de composants, dans lequel un système logiciel est
divisé en composants et interfaces qui sont réutilisables et
remplaçables.
14
Diagramme combiné de déploiement/composants
• Les diagrammes de composants sont distincts des

diagrammes de déploiement.
• Un diagramme de composants définit la composition des
composants et artefacts dans le système.
• Un diagramme de déploiement affiche les composants et
artefacts en relation avec l'emplacement où ils sont utilisés
dans le système déployé.
15
Éléments architecturaux (1)
Composant: une unité de calcul ou de données qui peut être

atomique ou composite et qui possède une interface décrivant
les points d’interaction du composant avec l’environnement.
• Il possède des dépendances explicitement définies pour
exprimer les exigences requises par son contexte
d’exécution ou sa réalisation.
• Les composants implémentent typiquement des services
spécifiques à l’application.
• La manifestation concrète d’un composant est appelé

artéfact (fichiers binaires, fichiers exécutables, etc.).
16
Interface de composant: permet à un composant d’exposer

les moyens à utiliser pour communiquer avec lui.
• On distingue deux types d’interfaces:
– Interface offerte : définit la façon de demander l’accès à un service
offert par le composant.
– Interface requise : définit le type de services requis par le
composant.
• Une interface est attachée à un port du composant:
– Un port est un point de communication du composant.
– Plusieurs interfaces peuvent être attachées à un même port
17
Dépendance entre composants: une relation entre deux

composants.
• On distingue trois types de dépendances:

– Dépendance fonctionnelle: Un composant peut dépendre d’un autre
composant qui lui fournit un service ou une information
– Dépendance de réalisation: Un composant peut dépendre d’une
classe qui implémente une partie de son comportement.
– Dépendance de manifestation: Un composant peut dépendre d’un
artefact (code source, fichier .jar, etc.) qui l’implante concrètement.
18
Connecteur: Un élément architectural qui définit le type

d’interactions entre les composants et les règles gouvernant
ces interactions.
• Un connecteur relie les ports de deux ou plusieurs
composants.
• Il décrit un mécanisme de connexion indépendant de
l’application.
• Les attributs du connecteurs décrivent ses propriétés
comportementales:
– sa capacité
– le temps de latence
– le type d’interaction (binaire/naire, asymétrique/symétrique,
détails du protocole, etc.)
19
Configuration: décrit la structure complète d’un système

sous la forme d’un graphe connexe regroupant des
composants et des connecteurs.
• Un langage de description architecturale (ADL) doit fournir
des aptitudes pour modéliser la configuration.
• Un ADL peut être un langage formel ou semi-formel, un
langage graphique, ou inclure les deux.
• L'intérêt d'utiliser un ADL réside dans la capacité à spécifier
rigoureusement une architecture afin de pouvoir l'analyser.
Exemples d’ADL: UML 2.0, Architecture Analysis & Design
Language (ADDL), Hierarchical Object Oriented Design
(HOOD).
20
Exemple 1: une configuration d’une application Wordpress

s’exécutant dans un contexte cloud.
21
Choix d’une architecture (1)
• Le choix d’architecture logicielle:

– Dépend des exigences fonctionnelles et non fonctionnelles du
logiciel.
– Choix favorisant la stabilité: l’ajout de nouveaux éléments sera
facile et n’exige que des ajustements mineurs à l’architecture.
– Influencé par certains styles architecturaux et de mode
d’interactions.
Style architectural: un patron décrivant une architecture
logicielle permettant de résoudre un problème particulier.
• Un ADL spécifie explicitement un style architectural et ainsi
qu’un mécanisme d’instanciation adéquat afin d’engendrer
des configurations conformes au style architectural.
22
• L’utilisation de styles architecturaux est l’un des piliers les

plus importants de l’architecture logicielle moderne.
Architecture pipeline:
• Convient bien aux systèmes de traitement et de transformation
de données.
• Composants = filtre ; Connecteur = canal
– Filtre: effectue la transformation/traitement des données et envoie
les données de sortie produites sur un ou plusieurs canaux de
sorties.
– Canal: permettant de faire circuler de manière unidirectionnel un flot
de données (stream).
23
Architecture MVC (Modèle-Vue-Contrôleur):

• Ce style d’AL est approprié pour les systèmes interactifs,
particulièrement ceux impliquant plusieurs vues du même
modèle de données.
• Il permet de séparer la couche interface utilisateur des autres
parties du système.
• Trois types de composants sont offerts par l’architecture MVC:
– Modèle: rassemble des données du domaine, des connaissances
du système. Contient les classes dont les instances doivent être
vues et manipulées.
– Vue: utilisé pour présenter/afficher les données du modèle dans l’interface
utilisateur.
– Contrôleur: contient les fonctionnalités nécessaires pour gérer et
contrôler les interactions de l’utilisateur avec la vue et le modèle.
24
• La figure suivante décrit l’architecture MVC.
25
Architecture n-niveaux:
• Pour les systèmes distribués qui peuvent être structurés en
couches.
• Rôles des composants et connecteurs:
– Composants : chaque niveaux est représenté par un composant qui joue le
rôle de client et/ou de serveur
– Connecteurs :
• Relient un client à un serveur.
• Connexion asymétrique.
• Doit supporter les communication distantes (e.g., requêtes RPC,
HTTP, TCP/IP)
• Architecture 2-niveaux: client-serveur
26
• Architecture 3-niveaux:
• Architecture 4-niveaux:
27
Vérification d’une architecture (1)
Question: Comment peut-on assurer la correction d'une

architecture logicielle (AL) décrite dans n’importe quel
formalisme adéquat ?
• Une AL est jugée correcte si et seulement si elle possède
des propriétés bien définies.
• Les propriétés à vérifier sur une AL sont classées en deux
classes:
– Propriétés standards: communes à n’importe quelle AL
– Propriétés spécifiques: propres à l’AL du système étudié
• Une architecture logicielle peut être représentée soit par un
modèle soit par un programme.
28
Vérification d’une architecture (2)
• Les techniques de vérification formelle applicables sur les

modèles et les programmes sont également applicables sur
les architectures logicielles.
• Avantages des méthodes formelles:
– Modèles précis, démarche rigoureuse, etc.
– Possibilité de (semi-) automatiser l’analyse des modèles.
• Méthodes formelles : Z, B, Event-B, Petri Nets, etc.
• Outils permettant vérifier une AL:
– UML-B: traduction des diagrammes UML est des modèles Event-B.
– ADAPT: Traduction des modèles architecturaux AADL aux réseaux de
Petri stochastiques.
– ACME Studio: permettant de vérifier une AL décrite en langage ACME.
29
Chapitre 2: Méthode B
30
Plan du chapitre
1. Introduction
2. Formalise de modélisation
3. Machines abstraites
4. Raffinement
5. Implémentation
31
Introduction
Origine: B est définit en 1996 par Jean-Raymond Abrial (un des

principaux concepteurs de Z dans les années 80).
• Cette méthode est fondée sur :
– Un formalise de modélisation: logique de prédicats, théorie des
ensembles
– Spécification des opérations : substitutions
– Les machines abstraites
– Le raffinement et l’implémentation
• Elle couvre :
– La spécification,
– La conception par raffinements successifs,
– L'architecture en couches,
– La génération du code exécutable.
• L'outil logiciel de support est l'atelierB 32
Formalise de modélisation: les prédicats
Primitives logiques:
• ⊤: désigne la valeur logique true.
• ⊥: désigne la valeur logique false.
Prédicat:
• Constitue l’élément clé de la logique de premier ordre.
• Bivalué: tout prédicat s’évalue soit à true ou à false.
• Souvent défini au moyen des connecteurs logiques:
– Négation: ¬P
– Conjonction: P∧Q
– Disjonction: P∨Q
– Implication: P⇒Q
– Équivalence: P⇔Q
33
Quantificateurs logiques:
• Quantificateur universel (∀)
• Quantificateur existentiel (∃)
Trois types de prédicats:
1. Prédicats atomiques: n’utilisent pas des connecteurs
logiques et ne sont pas quantifiés.
2. Prédicats non quantifiés (simples): n’utilisent pas des
quantificateurs.
3. Prédicats quantifiés: quantification universelle ou
quantification existentielle.
Exemple: le prédicat « x≠ 0 ∧ 𝑦 ÷ 𝑥 = 3 » se décompose
de deux prédicats atomiques « x≠ 0 » et « 𝑦 ÷ 𝑥 = 3 ».
34
Définition 1 : Un prédicat logique non quantifié F

se définie en Event-B selon l’une des formes
suivantes:
1. F= x, avec x ∈ {⊤, ⊥, p, q, r, …}
2. F=¬(G)
3. F=(G α H)
où
– α ∈ {∧, ∨, ⇒, ⇔}, et
– G et H sont des prédicats non quantifiés.
Exemple: le prédicat « x≠ 0 ∧ 𝑦 ÷ 𝑥 = 3 » est non
quantifié.
35
Définition 2 : Une quantification universelle F est

un prédicat Event-B qui se définit selon la syntaxe
suivante:
∀ 𝑥1 , … , 𝑥𝑛 . 𝑷 𝑥1 , … , 𝑥𝑛
• P est un prédicat (simple ou quantifié) définit en
fonction des paramètres 𝑥1 , … , 𝑥𝑛 .
• La quantification F est vraie si est seulement si le

prédicat P est vraie pour toutes les valeurs de
𝑥1 , … , 𝑥𝑛 .
36
Définition 3 : Une quantification existentielle F est

un prédicat Event-B qui se définit selon la syntaxe
suivante:
∃ 𝑥1 , … , 𝑥𝑛 . 𝑷 𝑥1 , … , 𝑥𝑛
• P est un prédicat (simple ou quantifié) définit en
fonction des paramètres 𝑥1 , … , 𝑥𝑛 .
• La quantification F est vraie si est seulement si le
prédicat P est vraie pour au moins une valeur de
𝑥1 , … , 𝑥𝑛 .
• La négation d’une quantification universelle est
une quantification existentielle.
37
• Egalité de deux expressions de même type:

– E1 = E2
– E1 ≠ E2
• Comparaison de deux expressions de type entier:
– E1 > E2
– E1 ≥ E2
– E1 ≤ E2
– E1 < E2
• Appartenance:
– e∈𝐸
– e∉𝐸
38
Formalise de modélisation: les ensembles (1/6)
• En B, il existe trois catégories de types de données :

– ℤ est l'ensemble de tous les entiers. L’ensemble des
entiers naturels ℕ est un sous type de ℤ.
– 𝐁𝐎𝐎𝐋 est l'ensemble des booléens. Il comporte deux
éléments BOOL = {TRUE, FALSE}.
– Types utilisateurs: ensembles énumérés/porteurs.
• A partir des types A et B deux autres types de données

peuvent être construits:
– P(A) contient les ensembles d'éléments de A.
– A x B est l’ensemble des pairs dont le premier
élément appartient à A et le second appartient à B.
39
• Un ensemble peut être défini de deux façons :

– en extension, c'est-à-dire en donnant la liste de ses
éléments entre accolades.
– en compréhension c'est-à-dire par une propriété
caractérisant ses éléments.
Définition 4: un ensemble S peut être définie en
compréhension selon l’une des syntaxes suivantes:
1. S= EP
2. S = 𝑖𝑑𝑠 . P E
où :
– P désigne un prédicat et E est une expression représentant les
éléments de S.
– ids est une liste d’identifiants.
40
• L'ensemble 𝑥1 , … , 𝑥𝑛 . P E contient toutes les valeurs de

E pour les valeurs de 𝑥1 , … , 𝑥𝑛 où le prédicat P est vrai.
• L'extension définie {𝑒1 , … , 𝑒𝑛 } est l'ensemble qui contient

exactement les éléments 𝑒1 , … , 𝑒𝑛 .
Exemples:
– A1 = {x. x ∈ 1. . 10 | x ∗ 2}
– A2 = {x^3|x ∈ 1. . 100}
– A3 = {1, 4, 9, 16, 25, 36, 49, 64, 81, 100}
41
Opérations de base sur les ensembles:

• Ensemble fini: finite(S)
• Cardinalité d’un ensemble fini: card(S)
• Ensemble des parties: P(S)
• Ensemble des parties non vides: P1 (S):
• Sous-ensemble: A1 ⊆ A2
• Inclusion stricte: A1 ⊂ A2
• Non-inclusion stricte: A1 ⊄ A2
• Non-inclusion large: A1 ⊈ A2
• Intersection: A1 ∩ A2
• Union: A1 ∪ A2
• Soustraction: A1 \ A2
42
Opérations complexes sur les ensembles

1. Union quantifiée:
– ‫ 𝟏𝐱 ڂ‬, … , 𝐱𝐧. 𝐏 | 𝐄
– ‫𝐏 | 𝐄ڂ‬
2. Intersection quantifiée:
– ‫ 𝟏𝐱 ځ‬, … , 𝐱𝐧. 𝐏 | 𝐄
– ‫𝐏 | 𝐄ځ‬
3. Union et intersection généralisées: union et inter
Définition 5: Pour un ensemble S dont les éléments sont des

ensembles, union(S) (resp. inter(S)) est l’ensemble obtenu
par l’union (resp. l’intersection) de tous les éléments de S.
43
Minimum:
• min(S) désigne le plus petit nombre de l'ensemble des
entiers S.
• Condition: l’ensemble S doit être non vide et minoré.
Maximum:
• max(S) désigne le plus grand nombre de l'ensemble des
entiers S.
• Condition: l’ensemble S doit être non vide et majoré.
Exemple:
• min({1,3,4,-3, 5,6})= -1;
• max({1,3,4,-3, 5,6})= 6;
44
Formalise de modélisation: les relations (1/5)
Produit cartésien:
• S×T désigne l'ensemble de paires où le premier élément est un
membre de S et le second élément est un membre de T. 𝐱 ↦ 𝐲 est la
paire dont le premier élément est x et le second élément est y.
Relations:
• S⟷T est l'ensemble de toutes les relations définies entre les
ensembles S et T.
• Une relation r (r∈S⟷T) est un ensemble de paires où le premier
élément est de S et le second de T.
• S⟷T est juste une abréviation pour P(S×T).
• r[X] est l’image de l’ensemble X par la relation r. Plus formellement, il
prédéfinit comme suit:
𝑟 𝑋 ≜ 𝑦 ∃ 𝑥. 𝑥 ∈ 𝑋 ∧ 𝑥 ↦ 𝑦 ∈ 𝑟 }
45
Relations totales:
• S T est l'ensemble de toutes les relations totales définies entre les
ensembles S et T.
• Une relation totale r est une relation qui relie chaque élément de S à
au moins un élément de T.
Relations surjectives:
• S T est l'ensemble de toutes les relations surjectives définies entre
les ensembles S et T.
• Une relation surjective r est une relation où il y a au moins un élément
de S pour chaque élément de T tel que les deux sont liés.
Relations surjectives totales:
• S T est l'ensemble de toutes les relations surjectives totales
définies entre les ensembles S et T.
• Une relation surjective totale r est une relation à la fois surjective et
totale.
46
Définition 6: Pour une relation r∈S⟷T, dom(r) (resp. ran(r))

est l’ensemble des éléments de S (resp. T) qui sont liés à au
moins un élément de T (resp. S) par r.
Restriction de domaine/codomaine:
• X ⊲ r: sous-ensemble de r qui contient toutes les paires dont le
premier élément est dans X.
• r ⊳ Y: sous-ensemble de r qui contient toutes les paires dont le
deuxième élément est dans Y.
Anti-restriction de domaine/codomaine:
• X r: un sous-ensemble de r qui contient toutes les paires dont
le premier élément n’est pas dans X.
• r Y: un sous-ensemble de r qui contient toutes les paires dont
le deuxième élément n’est pas dans Y.
47
Opérations sur les relations:

Opérations Description
r;s Un élément x est lié par la composition en avant r;s à un élément y
s'il existe un élément z tel que r relie x à z et S relie z à y.
r∘s Un élément x est lié par la composition en arrière r∘s à un élément y
s'il existe un élément z tel que s relie x à z et r relie z à y.
r||s Le produit parallèle r||s relie une paire x ↦ y à une paire m ↦ n
lorsque r relie x à m et s relie y à n.
r⨂s Si une relation r relie un élément x à y et s relie x à z, le produit r⨂s
relie x à la paire y↦z.
𝑟~ La relation inverse 𝑟~ relie un élément x à y si la relation d'origine r
relie y à x.
r s Cette opération overriding produisant une relation égale à r sauf que
toutes les entrées de r dont le premier élément est dans le domaine
de s sont remplacées par les entrées correspondantes de s.
48
Relations prédéfinies :
• id: la relation d'identité qui relie chaque élément à lui-même.
• 𝐩𝐫𝐣𝟏 : une fonction qui relie une paire à son premier élément.
• 𝐩𝐫𝐣𝟐 : une fonction qui relie une paire à son deuxième élément.
Remarque: les relations id, 𝐩𝐫𝐣𝟏 et 𝐩𝐫𝐣𝟐 sont des définitions

génériques. Leur type doit être déduit de l'environnement.
Exemple: L'hypothèse de la non-réflexivité d'une relation r,

définie sur un ensemble S, peut être exprimée par le prédicat
suivant:
(id ⊳ 𝑆) ∩ 𝑟 = ∅
49
Formalise de modélisation: les fonctions (1/4)
Définition 6 : une fonction définie de S dans T est une

relation qui relie un élément de S à au plus un élément de T.
• Propriétés des fonctions:
Fonctions partielles
Fonctions totales
Fonctions Fonctions injectives
Fonctions surjectives
Fonctions bijectives
50
Fonctions partielles:
• S T est l’ensemble des fonctions partielles.
• Une fonction partielle f de S à T est une relation qui relie un élément de S à au
plus un élément de T. Le domaine de f est inclut dans S.
• ∅ est un cas particulier de fonction partielle.
Fonctions totales:
• S → T est l’ensemble des fonctions totale.
• Une fonction totale f de S à T est une partielle dont le domaine est égale à S.
Fonctions injectives:
• S T est l’ensemble des fonctions injective partielle.
• S ↣ T est l’ensemble des fonctions injective totale.
• Une fonction est injective (totale ou partielle) si deux éléments distincts de S
sont toujours reliés à des éléments distincts de T.
• L’inverse d’une fonction injective est obligatoirement une fonction.
51
Fonctions surjectives:
• S T est l’ensemble des fonctions surjectives partielles.
• S ↠ T est l’ensemble des fonctions surjectives totales.
• Une fonction f de S à T est un surjective si pour chaque élément de T il existe
un élément dans S qui lui est relié.
Fonctions bijectives:
• S T est l’ensemble des fonctions bijectives.
• Une fonction est bijective si et seulement si elle est injective et surjective.
• L’inverse d’une fonction bijective est une fonction bijective.
52
Fonction lambda
• ⋌ 𝑝 . 𝐶 𝐸) est une fonction qui relie une entrée p à un résultat E tel
que le prédicat C soit vrai.
• p est un modèle d'identificateurs, de parenthèses et ↦ qui suit les
règles suivantes:
– Tout identifiant x est un modèle.
– Un paire x↦y est un modèle si x et y sont deux modèles.
– (a) est un modèle si a l’est aussi.
Exemples:
• Une fonction double qui renvoie la valeur double d'un nombre naturel:
𝑑𝑜𝑢𝑏𝑙𝑒 = ⋌ 𝑥 . 𝑥 ∈ ℕ 𝑥 ∗ 2)
• Fonction calculant le produit scalaire de vecteurs à deux-dimensions:
𝑑𝑜𝑡𝑝 = ⋌ 𝑎 ↦ 𝑏 ↦ 𝑐 ↦ 𝑑 . {𝑎, 𝑏, 𝑐, 𝑑} ⊂ ℤ 𝑎 ∗ 𝑐 + 𝑏 ∗ 𝑑)
53
Formalise de modélisation: exercice n°1
Soit un ensemble personne ⊆ PERSONNE. Modélisez les règles

suivantes:
• R1 : toute personne est soit un homme, soit une femme.
• R2 : une personne ne peut pas être à la fois un homme et
une femme.
• R3 : seules les femmes peuvent avoir un mari qui est un
homme.
• R4: les femmes ont au plus un mari.
• R5 : un homme ne peut être marié qu’a au plus une
femme.
• R6 : la mère d’une personne est une femme mariée.
54
Formalisez les règles suivantes décrivant partiellement un SI

d'un hôpital:
• R1: Un hôpital est constitué d’un certain nombre de
chambres numérotées de 1 à n.
• R2: Dans chaque chambre on trouve 1 ou plusieurs lits.
• R3: Les chambres ne disposent pas toutes du même
nombre de lits.
• R4: Une chambre peut être dans l’un des états suivants :
vide, pleine ou partiellement occupée.
• R5: Les malades sont répertoriés selon leur catégorie :
enfant, adulte homme, adulte femme.
• R6: Une chambre ne comporte que des malades d’une
même catégorie 55
Formalisez les règles ci-dessous d’une bibliothèque

universitaire:
• R1: Un exemplaire est toujours associé à un livre. Celui-ci
est unique.
• R2: Un même exemplaire de livre ne peut pas être
emprunté par différents abonnés.
• R3: Un même abonné ne peut pas emprunter plus d’un
exemplaire d’un même livre.
• R4: Un même abonné peut emprunter plusieurs livres.
56
Les machines abstraites (1)
• Une machine abstraite peut être comparée à un objet

comprenant :
– Un état interne (les variables)
– Des moyens d’actions sur cet état (les opérations).
• Elle est structurée en trois parties:

– Partie entête: nom de la machine
– Partie statique:
• La déclaration d’ensembles et de constantes
• Les propriétés des constantes
– Partie dynamique:
• Les variables décrivant l’état de la machine.
• L’invariant (caractérisation de l’état)
• L’initialisation des variables de la machine
• Les opérations 57
Syntaxe de base d’une machine abstraite:

MACHINE <Nom_de_la_machine>
Partie entête
SEES <Nom_autre_machine>
SETS /* liste des ensembles porteurs/énumérés */
CONSTANTS /* liste de constantes */ Partie
PROPERTIES statique
/* spécification des propriétés sur les constantes */
VARIABLES /* liste de variables */
INVARIANT /* spécification de l’invariant de machine */
INITIALISATION Partie
/* substitution d’initialisation des variables */ dynamique
OPERATIONS
/* liste des opérations */
END 58
• SETS: une liste d’ensembles porteurs/énumérés

set1[=val1]; set2[=val2];…; setk[=val_k]
• CONSTANTS: une liste des constantes.
ct1, ct2,…, ctk
• PROPERTIES: un prédicat exprimant des propriétés sur

les ensembles et les constantes.
• VARIABLES: une liste de variables, séparées par des
virgules, définissant l’état de la machine
v1, v2,…, vk
• INVARIANT: un prédicat exprimant des propriétés
invariantes de la machine.
59
• Une machine peut comporter uniquement des définitions

statiques du système.
• Elle peut avoir aussi un état (des variables sont définies).
• Dans ce cas, la machine doit comporter une ou plusieurs
opérations dont l’une est l’initialisation.
Syntaxes de base d’une opération:
nom_operation(pram1,…) = retour  nom_operation (pram1,…) =
PRE PRE
/* Précondition de l’opération */ /* Précondition de l’opération */
THEN THEN
/* liste d’actions*/ /* liste d’actions*/
END END
60
• Dans la clause PRE, on doit définir au moins les types des

paramètres de sorties ou d’entrées de l’opération.
• Les actions d'une opération sont définies au moyen des
substitutions généralisées.
• On distingue cinq formes de substitutions:
– Substitution simple: vv1:=E1
– Substitution ensembliste: vv1:∈E1
– Substitution parallèle ou multiple:
vv1:=E1|| vv2:=E2 ou bien vv1,vv2:=E1,E2
– Substitution préconditionnée: PRE C THEN S
– Substitution indéterminée:
ANY xx1,… WHERE C1 THEN S1
CHOICE S1 OR S2 … OR S3
61
Exemple 1: la machine suivante modélise le fonctionnement

d’un système de gestion de circulation d’un carrefour.
MACHINE INVARIANT
M0 etat:Etats ∧
SETS feuA ∈ Couleurs ∧
Etats={hs,es}; feuB ∈ Couleurs ∧
Couleurs={vert,orange,rouge} (etat=hs
CONSTANTS ⇒
Succ (feuA=orange & feuB=orange)) ∧
PROPERTIES (etat=es
Succ: Couleurs → Couleurs ∧ ⇒
Succ(orange) = rouge ∧ ( feuA=rouge or feuB=rouge) ∧
Succ(rouge) = vert ∧ feuA/=feuB
Succ(vert) = orange )
VARIABLES INITIALISATION
etat,feuA,feuB etat, feuA,feuB:=hs,orange,orange
62
• La machine M0 comporte, outre l’initialisation, des deux

opérations suivantes:
MiseEnService (f1,f2) = ChangeEtat(f1,f2)=
PRE PRE
etat=hs ∧ f1∈Couleurs ∧ f2∈Couleurs ∧
f1∈Couleurs ∧ f2∈Couleurs ∧ (f1=rouge or f2= rouge) ∧
(f1 = rouge ∨ f2 = rouge) ∧ f1≠f2 ∧
f1/= f2 (f1=Succ(feuA) ∨ f2=Succ(feuB))
THEN THEN
etat,feuA,feuB:=es,f1,f2 feuA,feuB:=f1,f2
END; END;
• L’opération MiseEnService permet de mettre le système

en service.
• L’opération ChangeEtat permet de changer les couleurs
des deux feux. 63
Exemple 2: On veut spécifier une opération qui alloue un

mot dans une mémoire. La modélisation B d’une telle
opération se fait par la machine suivante.
MACHINE M0
SETS ADRESSES
CONSTANTS memoire, null
PROPERTIES
memoire ⊆ ADRESSES ∧ null ∈ ADRESSES ∧ null ∉ mémoire
VARIABLES libres
INVARIANT libres ⊆ memoire
INITIALISATION
libres:=mémoire
OPERATIONS
mot allouer= …..
END
64
• L’opération allouer ne peut agir que s’il reste encore un

espace mémoire libre.
• Première modélisation: une précondition assure qu’il reste
de la place.
mot <-- allouer = // l’entête de l'opération
PRE libres ≠ {} THEN
ANY vv
WHERE
vv ∈ libres // choix d’une adresse libre
THEN
libres:=libres-{vv}||mot:=vv // retour de l'adresse allouée
END
END
END
65
• Autre manière de spécifier: l’utilisateur n’a pas à tester la

précondition.
• Si l’adresse de retour est null, cela signifie à l’utilisateur
que la mémoire est pleine et que l’allocation n’a pas été
possible.
IF libres ≠ {} THEN
ANY vv WHERE vv ∈ libres // choix d’une adresse libre
THEN
END
ELSE // il n’y a plus d’adresse libre
mot:=null //
END
END
66
• On pourrait utiliser l’instruction « CHOICE S1 OR S2 »

pour spécifier l’opération allouer avec les deux cas
possibles de retour de valeur de mot.
CHOICE
ANY vv
WHERE
vv ∈ libres // choix d’une adresse libre
THEN
END
OR // il n’y a plus d’adresse libre
mot:=null //
END
END
67
Raffinement (1)
• Le raffinement est une technique de développement proche à

la notion d’héritage de classes en POO.
• Le raffinement d’une machine B se fait selon trois volets:

– Raffinement de données: introduction de nouvelles données
(ensembles, constantes et variables concrètes).
– Raffinement de contrôle: Élargissement des préconditions et
réduction du non-déterminisme (choix de solutions ou d’options)
– Raffinement algorithmique: Utilisation de structures de contrôle des
langages de programmation : séquence et itération WHILE
Principes de raffinement:
P1) Raffiner le modèle B jusqu’à obtenir un modèle complètement
concrétisé.
P2) Assurer que tous les raffinements sont corrects et conformes au
modèle initial. 68
Raffinement (2)
Forme générale d’un raffinement
69
Raffinement (3)
• Entre la machine abstraite et le raffinement, il y a changement de

variable.
• L’invariant de la machine raffinement doit mettre en relation les
variables abstraites et raffinées: c’est l’invariant de liaison.
70
Raffinement (4)
• Entre la machine abstraite et le raffinement, il ne doit pas y avoir

de changement de signature: mêmes opérations avec les
mêmes paramètres.
• La machine abstraite peut être remplacée par la machine
concrète sans que l’utilisateur de la machine ne puisse s’en
rendre compte.
71
Raffinement (5)
Raffinement de substitutions:
• Étant données deux substitutions S et T dans le contexte d’une
machine abstraite M,
• S est raffinée par T si T peut être utilisé à la place de S sans que
l’utilisateur de la machine puisse s’en rendre compte.
• Pour cela, il faut que la précondition de T soit plus faible que celle de S, et T
soit plus déterministe que S.
Réduction de l’indéterminisme:
• Lors de la conception d’une maison, l’architecte ne précise pas tout
dès le début. Il laisse des zones imprécises. ➔l’indéterminisme
• Par exemple, il ne précise pas le matériau du toit. Il écrit “toit en tuiles
ou en ardoises”. Cependant, ce choix devra être fait avant la fin de la
construction.
➔il faudra résoudre l’indéterminisme
72
Raffinement (6)
Exemple d’affaiblissement de précondition: qui peut le plus,

peut le moins.
73
Raffinement (7)
Exemple de réduction de l’indéterminisme:
74
Implémentation (1)
• Spécification abstraite : spécification des propriétés, pas de

séquence, pas d’itération.
• Implémentation: raffinement traduisible en un programme

Ada, C, C++, ...
• Langage B0: séquences, itérations, pas de non-

déterminisme, pas de précondition, types de données
concrets.
• On peut la séquence de substitutions « S;T », et des

itérations while (WHILE Condition DO S END).
• Les clauses suivantes sont interdites dans l’ Implémentation:
– ABSTRACT_CONSTANTS
– ABSTRACT_VARIABLES
75
Implémentation (2)
Forme générale d’une implémentation:
76
Implémentation (3)
Substitutions d’une implémentation:

• Substitutions déterministes = Instructions
• Pas de préconditions (la substitution PRE… THEN n’est pas
autorisée).
• Les instructions possibles:
– Instruction séquence: I1 ; I2
– Bloc d’instructions: BEGIN I END
– Instruction sur les variables locales: VAR aa,bb IN I END
– Instructions devient égal: aa,bb:=vv, ww
– Instruction conditionnelle:
• Instruction IF: IF P THEN I1 [ELSIF C2 THEN I2 ] [… ] END
• Instruction ASSERT: ASSERT C1 THEN I1 END
• Instruction CASE: CASE E OF
EITHER v1 THEN I1 OR v2 THEN I2 ...
[ELSE In END ]
END 77
Implémentation (4)
Exemple: on veut modéliser un module d’allocation

d’adresse mémoire libre.
• Une première modélisation de ce module pourrait la
suivante:
78
Implémentation (5)
• La machine MEMEORY peut être raffinée de la manière

suivante:
79
Implémentation (6)
• Une implémentation possible de la machine MEMORY_r:
80
Chapitre 3: Méthode Event-B
81
Introduction
• La méthode Event-B est une évolution de B et développée par

Jean-Raymond ABRIAL dans son livre en 2010.
• Elle offre des moyens permettant de modéliser aussi bien les

données que les traitements:
– Les données sont modélisées par un langage logico-ensembliste
(logique de prédicats, théorie des ensembles).
– Les traitements à l’aide d’un langage d’actions simple et de
substitutions généralisées offrant plusieurs niveaux d’abstractions.
• Concepts clés d’Event-B:

– Contexte et Machine
– Evènement
– Raffinement
82
Contexte (1/3)
Syntaxe générale d’un contexte:
CONTEXT < context_identifier >

[EXTENDS < context_identifier_list >]
SETS
< set_identifier_list >
CONSTANTS
< constant_identifier_list >
AXIOMS
< label > : < predicate >
...
END
83
Contexte (2/3)
• La construction CONTEXT permet de décrire la partie

statique d’un modèle Event-B.
• Un contexte en Event B peut comporter :

– Un ensemble : énumérés ou différés => concepts métier ou
notions issues de l’application=> clause SETS.
– Constantes : clause CONSTANTS.
– Contraintes : permettant de typer les constantes et de préciser les
propriétés relatives aux ensembles et aux constantes => clause
AXIOMS.
• Un contexte peut étendre un autre Contexte. C’est la

clause « EXTENDS ». On verra ultérieurement ce concept
avec plus de détails.
84
Contexte (3/3)
Exemple 1: Le contexte suivant modélise les règles présentées

dans l’exercice précédant.
CONTEXT ctx0
SETS Personne
CONSTANTS homme femme mariage mère
AXIOMS
axm1: homme∈ℙ(Personne)∧femme∈ℙ(Personne)
axm2: mariage∈ℙ(Personne×Personne)∧mère∈ℙ(Personne×Personne)
R1: Personne=femme ∪ homme
R2: homme∩femme = ∅
R3: dom(mariage)⊆femme∧ran(mariage)⊆homme
R4: ∀f·f∈femme∧finite(mariage[{f}]) ⇒ card(mariage[{f}])≤1
R5: ∀h·h∈homme∧finite(mariage∼[{h}]) ⇒ card(mariage[{h}])≤1
R6: ∀m·m∈dom(mère) ⇒ m∈dom(mariage)
END 85
Machine (1/3)
Syntaxe générale d’une machine:

MACHINE < machine_identifier >
[REFINES < machine_identifier >]
SEES < context_identifier_list >
VARIABLES
< variable_identifier_list >
INVARIANTS
...
VARIANT
...
EVENTS
< event_list >
END
86
Machine (2/3)
• La construction MACHINE en Event-B, permet de modéliser la

partie dynamique d’un modèle Event-B.
• Elle peut comporter :
– Variables : peuvent être modifiées par les évènements =>
clause VARIABLES
– Invariants: permet de décrire les propriétés invariantes des
variables => clause INVARIANTS.
– Evènements: avec un évènement particulier appelé
INITIALISATION => clause EVENTS.
– Variante: permet de décrire une propriété de convergence
des évènements => clause VARIANT.
• La liste des contextes vus par une machine est explicitement
définie dans la clause sees.
87
Machine (3/3)
Exemple 2: la machine suivante modélise la fonction

factorielle d’entiers.
MACHINE m0
VARIABLES f
INVARIANTS
inv1: f ∈ ℕ⇸ℕ
EVENTS
INITIALISATION
THEN
act1: f ≔ {0↦1}
END
...
END
88
Évènement (1/4)
• Une machine peut éventuellement contenir des évènements

permettant de faire évoluer cet état initial.
• Un évènement représente un changement de l’état des
variables de la machine où il est défini.
• Un évènement peut avoir l’un des états de convergence
suivants:
– ordinaire (ordinary): lorsqu'il peut se produire de manière
arbitraire et ne dispose pas de restriction concernant la
variante de la machine.
– Convergent: lorsqu'il doit diminuer la variante de la
machine.
– Anticipé (anticipated): lorsqu’il ne doit pas augmenter la
variante de la machine.
89
Évènement (2/4)
Structure générale d’un évènement:

EVENT < event_identifier >
STATUS <event_status>
REFINES < event_identifier_list >
ANY < parameter_identifier_list >
WHERE
...
WITH
<label>: < predicate >
...
THEN
< label > : < action >
...
END
90
Évènement (3/4)
• Les actions représentent la façon dont les variables de la

machine correspondante sont évoluées.
• La méthode Event-B fournit trois formes de substitution:
– Substitution généralisée
𝑥: | 𝑃(𝑥, 𝑥′)
– Substitution ensembliste
𝑥: ∈ 𝐸 𝑥
– Substitution simple
𝑥≔𝐸 𝑥
• 𝑥 ′ représente la valeur de la variable x après l’exécution
de l’événement.
• P est un prédicat défini en fonction de x et x’. Il s’agit d’une
conjonction de deux implications logiques.
91
Évènement (4/4)
Exemple 3: un évènement factorielle de la machine m0.

Event factorielle
STATUS ordinary
ANY n
WHERE
grd1: n∈ℕ
grd2: n−1∈dom(f)
THEN
act1: f(n)≔n∗f(n−1)
END
• Cet évènement permet de calculer le factorielle d’un entier

n passé en paramètre.
92
Raffinement (1/2)
• Le raffinement d'un modèle Event-B (abstrait) se fait selon

deux volets:
– Extension de contexte.
– Raffinement de machine.
• Un contexte peut étendre un ou plusieurs autres

contextes. On rajoute, dans ce cas, la liste des contextes
étendus dans la clause extends du nouveau contexte.
• Une machine voit implicitement tous les contextes étendus

par un contexte explicitement vu.
• Une machine peut, au plus, raffine une seule autre

machine.
93
Raffinement (2/2)
• La relation « extends » en Event-B est une relation transitive. Elle ne

doit pas entraîner des cycles.
• Les relations entre « refines » et « extends » mises en place ne
doivent pas conduire à un cycle.
• Tout cela est illustré dans la figure suivante:
94
Etude de cas (1/3)
Un système de gestion de cours d'une institution.

• L'institution a des membres fixes; parmi eux se trouvent
des enseignants et des participants.
• Un membre peut être à la fois un enseignant et un

participant.
• Les contraintes fonctionnelles du système sont énumérées

ci-dessous:
– REQ1 : Les enseignants sont des membres du club.
– REQ2 : Les participants sont des membres du club.
– REQ3 : Il existe des cours prédéfinis.
– REQ4 : Chaque cours est attribué à un enseignant fixe.
– REQ5 : Un cours est soit ouvert ou fermé.
95
Etude de cas (2/3)
– REQ6 : Le système permet d'ouvrir un cours déjà fermé.

– REQ7 : Le système permet de fermer un cours ouvert.
– REQ8 : Le nombre de cours ouverts ne peut dépasser pas une
limite donnée.
– REQ9 : Les participants ne peuvent s'inscrire qu'à un cours ouvert.
– REQ10 : Les enseignants ne peuvent pas suivre leurs propres
cours.
Questions:
• Proposez une modélisation incrémentale en Event-B de ce
système.
• Testez le modèle proposé sur un exemple concret en
utilisant ProB.
96
Etude de cas (3/3)
Réponse:
• Pour modéliser le système de gestion de cours, nous adoptons la
démarche suivante:
– Étape 1: modélisation des contraintes d'ouverture et de
fermeture des cours.
– Étape 2: modélisation des contraintes de participation aux
cours ouverts.
• La figure suivante présente une vue d'ensemble de l'architecture du
modèle obtenu.
97
Modèle initial (1/3)
• Initialement, nous nous concentrons

sur l'ouverture et la fermeture des
cours par le système.
CONTEXT C0
• Notre contexte initial C0 contient
SETS COURS
donc un ensemble COURS
CONSTANTS m
désignant les cours qui peuvent être
proposés par l'institue (REQ 3). AXIOMS
axm1 : finite(COURS)
axm2 : m∈ℕ1
• De plus, le contexte comprend une
axm3 : m ≤ card(COURS)
constante m indiquant le nombre
END
maximum de cours que l'institue
peut ouvrir en même temps (REQ
8).
98
• Compte tenu du contexte C0, nous

modélisons, dans la machine initiale M0,
les cours ouverts par une variable crs MACHINE M0
(REQ5). SEES C0
VARIABLES cours
• L'invariant inv1 indique qu'il s'agit d'un INVARIANTS
inv1 : cours∈ℙ(COURS)
sous-ensemble de cours disponibles.
inv2 : card(cours) ≤ m
EVENTS
• L’invariant inv2 modélise la contrainte INITIALISATION
REQ 8 THEN
act1: cours := ∅
• Au départ, tous les cours sont fermés; END
donc cours=∅. ...
END
99
• Dans la machine M0, nous modélisons les opérations d’ouverture et

de fermeture des cours par les deux suivants:
Event ouvrir Event fermer

status ordinary status anticipated
any crs any crs
when where
grd1 : crs⊆COURS grd1 : crs ⊆ cours
grd2 : crs≠∅∧crs∩cours=∅ grd2 : crs ≠ ∅
grd3 : card(cours ∪ crs)≤m then
then act1 : cours := cours \ crs
act1 : cours := cours ∪ crs end
end
• L’événement fermer est défini comme anticipé, car il va être dans

le premier raffinement convergent. 100
Premier raffinement (1/5)
• Avant de raffiner la machine M0, nous étendons tout d'abord le

contexte C0.
• L’objet de cette extension est de définir les propriétés statiques
associées aux membres, participants et aux enseignants.
• La description du nouveau contexte C1 est la suivante:
CONTEXT C1 EXTENDS C0
SETS MEMBRE
CONSTANTS Enseignants ensCours Participants
AXIOMS
axm1: finite(MEMBRE)
axm2: Enseignants∈ℙ(MEMBRE)
axm3: Participants∈ℙ(MEMBRE)
axm4: ensCours∈COURS→Enseignants
axm5: finite(Participants)
END 101
• Le raffinement de la machine M0 se résume par les points suivants:

– Introduction d’une nouvelle variable inscription. Le type de
cette variable est défini à l’aide d’un invariant comme suit:
inscription ∈ COURS⇸ℙ(Participants)
– La suppression de la variable abstraite cours. Un invariant de
témoin est donc défini afin d’établir le lien les variables cours et
inscription:
cours=dom(inscription)
– Le raffinement des évènements ouvrir et fermer en remplaçant
la variable cours par la variable inscription. L’évènement
raffiné fermer est convergent. Le variant de convergence est
l’expression suivante:
inscription
– L’introduction d’un nouveau évènement participer.
102
• La description de la machine M1 est la suivante :

MACHINE M1 REFINES M0
SEES C1
VARIABLES inscription
INVARIANTS
inv1: inscription ∈ COURS⇸ℙ(Participants)
inv2: ∀c·c∈dom(inscription)⇒ensCours(c)∉inscription(c)
inv3: cours=dom(inscription)
inv4: finite(inscription)
VARIANT
inscription
EVENTS
Event INITIALISATION STATUS ordinary
BEGIN
act1: inscription ≔ ∅
END
...
END
103
• La version concrète (raffinée) de chacun des évènements, ouvrir et

fermer, est la suivante:
Event ouvrir
Event fermer
status ordinary
status convergent
REFINES ouvrir
REFINES fermer
any crs
any crs
when
where
grd1 : crs⊆COURS
grd1 : crs⊆dom(inscription)
grd2 : crs≠∅∧crs∩dom(inscription) =∅
grd2 : crs ≠ ∅
grd3 : card(dom(inscription) ∪ crs)≤m
then
then
act1 : inscription≔crs⩤inscription
act1 : inscription≔inscription<+(crs×{∅})
end
end
104
• La modélisation de la participation à un cours ouvert se fait par

l’évènement suivant:
Event participer
STATUS ordinary
ANY p cr
WHERE
grd1 : cr∈dom(inscription)
grd2 : p∈Participants
grd3 : p≠ensCours(cr)
grd4 : p∉inscription(cr)
THEN
act1 : inscription(cr)≔inscription(cr) ∪ {p}
END
105
Correction d’un modèle Event-B (1)
• La correction d’un modèle Event-B est assurée en déchargeant

(démontrant) un ensemble d’obligations de preuve (OP) qui définissent
ce qui doit être prouvé pour un modèle Event-B.
• Elles sont générées automatiquement par un composant Rodin appelé

"Proof Obligation Generator". Ce composant vérifie statiquement les
textes d’un contexte ou d’une machine. Il décide alors ce qu’il faut
prouver dans ces textes.
• Le résultat est divers séquents, qui sont transmis aux prouveurs

effectuant des preuves automatiques ou interactives.
Définition 8: Un séquent a la forme suivante :

𝐇⊢𝐆
où G est un prédicat qui représente le but à prouver à partir de
l’hypothèse H.
106
• Dans ce qui suit, nous décrivons les différents types d’obligations de

preuve utilisés particulièrement dans notre travail. Nous utiliserons
systématiquement un événement evt ayant la forme suivante:
ANY x
WHERE G(s,c,v,x)
THEN v :| BA(s,c,v,x,v’)
END
où
– s et c désignent respectivement un ensemble et une constante.
– x désigne un paramètre de l’événement.
– v représente une variable de la machine.
• Les axiomes sont désignés collectivement par A(s, c), tandis que les
invariants sont désignés par I(s, c, v).
• Dans une machine raffinée, les variables concrètes seront désignées
par w et les invariants locaux par J(s, c, w). 107
Préservation d’invariants:
• Cette obligation de preuve garantit que chaque événement, y compris
l’initialisation, dans une machine doit préserver tous les invariants.
• Pour un événement evt et un invariant inv(s, c, v), l’obligation de

preuve est nommée : "evt/inv/INV".
• Pour décharger (démontrer) cette obligation de preuve, il faut prouver

le séquent suivant :
A(s, c) ∧
I(s, c, v) ∧
G(s, c, v, x)∧
BA(s, c, v, x, v’)
⊢
G(s,c,v’)
108
Renforcement de gardes abstraites:

• Le but de cette obligation de preuve est de s’assurer que lorsqu’un
événement concret est activé, l’événement abstrait correspondant est
également activé.
• Pour un évènement concret evt et une garde abstraite grd dans

l’événement abstrait correspondant evt0, le nom de cette obligation de
preuve est : "evt/grd/GRD".
• Le déchargement de cette obligation de preuve revient à démontrer le

séquent suivant :
EVENT evt REFINES evt0
A(s,c) ∧
ANY 𝒙𝒓
I(s,c,v) ∧
WHERE 𝑮𝒓 (s,c,w,𝒙𝒓 )
J(s,c,w) ∧
THEN w :| BA(s,c,𝒙𝒓 ,𝒘𝟎 )
𝑮𝒓 (s,c,w, 𝒙𝒓 )
END
⊢
G(s,c,v,x) 109
Bonne définition de prédicats:

• Cette obligation de preuve signifie que tous les invariants, les gardes,
les actions et les axiomes doivent être bien définis.
• Il n’est pas toujours affiché par RODIN s’il est trivial.
• L’ordre des invariants, des gardes et des axiomes est très important.
• Le tableau suivant illustre les conditions définition de quelques
expression mathématique.
Expression mathématique Condition de bonne définition
inter(S) 𝑆≠∅
f(E) f est une fonction partielle et 𝐸 ∈ 𝑑𝑜𝑚 𝐹
x mod y y>0
x/y 𝑦≠∅
card(S) 𝑓𝑖𝑛𝑖𝑡𝑒 𝑆
min(S) 𝑆 ≠ ∅ ∧ ∃𝑥. ∀𝑛. 𝑛 ∈ 𝑆 ⇒ 𝑥 ≤ 𝑛
max(S) 𝑆 ≠ ∅ ∧ ∃𝑥. ∀𝑛. 𝑛 ∈ 𝑆 ⇒ 𝑥 ≥ 𝑛
110
Test de modèle avec ProB (1/4)
• ProB est un outil intégré à la Platform Rodin permettant de tester

des modèles Event-B abstraits sur des scénarios représentatifs.
• Ceci permet d’intégrer des cas non traités initialement et de signaler

des erreurs de spécification.
• Par rapport à notre étude cas, on va créer une machine M2 qui

raffine la machine M1 et qui voit un nouveau contexte C2 qui décrit
un scénario de test de notre modèle Évent-B.
• La machine M2 n’introduit pas de nouveaux concepts, mais elle va

être utilisée uniquement pour tester notre modèle.
• Le contexte C2 est construit par extension du contexte C1. Il

propose un exemple de concrétisation de tous les ensembles et
constantes.
111
Description du contexte C2:
CONTEXT C2
EXTENDS C1
CONSTANTS
algorithmique java eventB
imed lazhar
abir sarra amira rahma
AXIOMS
axm1: partition(COURS,{algorithmique},{java},{eventB})
axm2: partition(MEMBRE,{imed},{abir},{lazhar},{sarra},{amira},{rahma})
axm3: partition(Enseignants,{imed},{lazhar})
axm4: partition(Participants,{abir},{sarra},{amira},{rahma})
axm5: partition(ensCours,{algorithmique↦lazhar},{java↦imed},{eventB↦imed})
axm6: m=3
END
112
• Pour lancer l'animation avec ProB, on peut procéder comme suit:

1- Effectuer un clic droit sur la machine M2
2- Cliquer sur animation/Model checking
3- Cliquer sur SETUP_CONTEXT
• Au début, seul l’évènement d'initialisation est activé.
• Une fois exécuté un tel évènement, on peut explorer le

comportement de notre modèle.
• Ceci s'effectue par exécution des évènements suivants: ouvrir,

fermer et participer.
113
114

CR-Méthodes Formelles

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CR-Méthodes Formelles

Transféré par

Droits d'auteur :

Formats disponibles

DocuSign Envelope ID: F90469B8-B4C2-466A-B666-3ABF970171D5

Institut Supérieur d'Informatique et de Mathématiques de

I. Les concepts de base d’architecture

Chapitre 1: concepts de base

• L’architecture d’un logiciel décrit la structure des modules

Avantages d’une architecture logicielle:

• Évolution: met en évidence les points où un système peut

• La conception architecturale est une étape primordiale

• Une architecture faible ou absente peut entraîner de graves

Modélisation avec UML (1)

• En UML, l'architecture d'une application logicielle est

Modélisation avec UML (2)

• Un programme peut être structuré en trois vues

Vue structurelle (modèle statique) Niveau 1

Vue du comportement et des interactions (modèle dynamique) Niveau 3

Modélisation avec UML (3)

Modélisation avec UML (4)

• Exemple de packages contenant des classes

Modélisation avec UML (5)

• Ce diagramme représente la structure du système logiciel,

Modélisation avec UML (6)

Diagramme combiné de déploiement/composants

• Les diagrammes de composants sont distincts des

Éléments architecturaux (1)

Composant: une unité de calcul ou de données qui peut être

• La manifestation concrète d’un composant est appelé

Éléments architecturaux (2)

Interface de composant: permet à un composant d’exposer

Éléments architecturaux (3)

Dépendance entre composants: une relation entre deux

• On distingue trois types de dépendances:

Éléments architecturaux (4)

Connecteur: Un élément architectural qui définit le type

Éléments architecturaux (5)

Configuration: décrit la structure complète d’un système

Éléments architecturaux (6)

Exemple 1: une configuration d’une application Wordpress

Choix d’une architecture (1)

• Le choix d’architecture logicielle:

Choix d’une architecture (2)

• L’utilisation de styles architecturaux est l’un des piliers les

Choix d’une architecture (3)

Architecture MVC (Modèle-Vue-Contrôleur):

Choix d’une architecture (4)

• La figure suivante décrit l’architecture MVC.

Choix d’une architecture (5)

Choix d’une architecture (6)

Vérification d’une architecture (1)

Question: Comment peut-on assurer la correction d'une

Vérification d’une architecture (2)

• Les techniques de vérification formelle applicables sur les

Origine: B est définit en 1996 par Jean-Raymond Abrial (un des

Formalise de modélisation: les prédicats

Formalise de modélisation: les prédicats

Formalise de modélisation: les prédicats

Définition 1 : Un prédicat logique non quantifié F

Formalise de modélisation: les prédicats

Définition 2 : Une quantification universelle F est

• La quantification F est vraie si est seulement si le

Formalise de modélisation: les prédicats

Définition 3 : Une quantification existentielle F est

Formalise de modélisation: les prédicats

• Egalité de deux expressions de même type: