Méthodes Formelles de spécification et développement
Cycle de Balzer
Réalisée par : M O U N A A B D E L L AO U I GL5 A N N É E U N I V E R S I TA I R E : 2019/2020
Plan
Introduction
1. Cycle de vie d’un logiciel
2. Cycle de Balzer
a. développement incrémental
b. spécifications formalisées
3. Conclusion
Bibliographie
2
Introduction
L’apparition d’applications de plus en plus critiques (en termes de coût, de
sécurité des personnes et des installations, en termes d’image de marque de
l’entreprise), remet en cause la production du logiciel pour ‘ramener’
l’informatique à ses sources, les mathématiques.
Depuis quelques années, la tendance est donc vers l’utilisation de méthodes
formelles dans tout le cycle de vie du logiciel. On parle plutôt d’utilisation de
méthodes formelles.
Ces dernières peuvent être des méthodes de spécification, de transformation et
dérivation, d’analyse, de preuve, de test...
On parle de méthode formelle, lorsque le langage utilisé possède une syntaxe
et une sémantique fondées sur les mathématiques (logique, algèbre,
probabilité...).
3
1. Cycle de vie d’un logiciel
Comme pour toutes les fabrications, il est important
d’avoir un procédé de fabrication du logiciel bien
défini et explicitement décrit et documenté .
Les modèles de cycle de vie du logiciel décrivent à
un niveau très abstrait et idéalisé les différentes
manières d’organiser la production.
Les étapes, leur ordonnancement, et parfois les
critères pour passer d’une étape à une autre sont
explicités .
4
Il y a plusieurs cycles de vie du logiciel , par exemple :
cycle en Cascade (1970) [1]
cycle en V (années 1980) [2]
cycle en Spirale (Boehm 88) [3]
cycle de Balzer (Balzer, 1989) [4]
cycle itératif (1990, utilise dans les méthodes RAD Rapid Application Développent)
Méthodes agiles ( issues des pratiques de ces précédents cycles, spirale, RAD, XP) etc.
Ils sont choisis et appliqués selon les besoins du projet à développer.
5
[3]
[1]
[2]
[4]
6
[Link] de Balzer
Tous les cycles de vie classiques ne marchent
pas avec les méthodes formelles.
Il faut les adapter.
Le cycle de vie de Balzer représente une
nouvelle famille de cycles de vie adapté au
développement formel (ou rigoureux) .
transformation systématique des
spécifications en programmes en
utilisant des lois prédéfinies.
7
Le modèle de Balzer associe:
développement incrémental
utilisation de spécifications
formalisées
elles même développées
de manière incrémentale
et maintenues .
8
a. Spécification formelle :
Action de décrire sans ambiguïté un modèle conceptuel, en général au
moyen d'une méthode ou d'un langage, comme NIAM, UML,
EXPRESS-G, ...
L'objectif d'une méthode de spécification formelle est de pouvoir
décrire des concepts peut-être compliqués, mais finalement rendus très
simples, car on peut toujours décomposer un objet complexe en sous-
objets élémentaires.
Cette méthode de décomposition permet au modèle conceptuel de
représenter un aspect du réel sans erreurs d'interprétation possibles.
9
a . Le développement incrémental :
Le développement incrémental consiste à réaliser successivement
des éléments fonctionnels utilisables, plutôt que des composants
techniques.
Un découpage en incréments est dit "vertical", en référence à
l'imagerie habituelle qui présente les composants techniques d'une
architecture logicielle comme les couches empilées d'un gâteau.
Un incrément est une fonctionnalité complète,
métaphoriquement une tranche verticale du gâteau.
Une approche incrémentale implique nécessairement d'adopter
également, au moins dans une certaine mesure, une
approche itérative, mais les deux concepts ne sont pas identiques.
10
Conclusion : Modèle idéal ?
Il n’y a pas de modèle idéal car tout dépend des circonstances.
◦ Le modèle en cascade ou en V est risqué pour les développements innovants car les
spécifications et la conception risquent d’être inadéquats et souvent remis en cause.
◦ Le modèle incrémental est risqué car il ne donne pas beaucoup de visibilité sur le
processus complet.
◦ Le modèle en spirale est un canevas plus général qui inclut l’évaluation des risques.
◦ Le modèle de Balzer est risqué car il exige des spécialistes de très haut niveau.
Souvent, un même projet peut mêler différentes approches, comme le prototypage pour
les sous systèmes à haut risque et la cascade pour les sous systèmes bien connus est à
faible risque.
11
Merci pour votre attention .
12
Bibliographie
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[19/11/2019]
13
