modulatié et programmation raisonnée
This commit is contained in:
gwen
parent
57244e006e
commit
141f4a12a7
|
|
@ -1,47 +1,19 @@
|
|||
manips sur les structures de données de base
|
||||
Exercices complémentaires
|
||||
--------------------------
|
||||
|
||||
- structures de données
|
||||
+ (),[],{}
|
||||
+ listes en compréhension
|
||||
|
||||
- éléments du langage
|
||||
boucles, conditions, fonctions, itérateur, map , enumerate
|
||||
|
||||
+ **Manipulation de quelques structures de données**:
|
||||
chaînes de caractères (création, accès à un caractère, concaténation), listes (création, ajout
|
||||
+ **Manipulation de chaînes de caractères**:
|
||||
(création, accès à un caractère, concaténation), listes (création, ajout
|
||||
d’un élément, suppression d’un élément, accès à un élément, extraction d’une partie de liste), tableaux à une ou plusieurs dimensions.
|
||||
|
||||
On met en évidence le fait que certaines opérations d’apparence simple cachent
|
||||
un important travail pour le processeur. On met à profit la structure de
|
||||
tableau d’entiers à deux dimensions pour introduire la notion d’image
|
||||
ponctuelle (« bitmap »). Les algorithmes de traitement d’image seront abordés
|
||||
plus tard.
|
||||
|
||||
+ **Fichiers** :
|
||||
notion de chemin d’accès, lecture et écriture de données numériques ou de type chaîne de caractères depuis ou vers un fichier.
|
||||
|
||||
On encourage l’utilisation de fichiers en tant que supports de données ou de résultats avant divers traitements, par exemple graphiques.
|
||||
|
||||
+ **Piles**
|
||||
Algorithmes de manipulation : fonctions 'push' et 'pop'. On utilise des listes
|
||||
(ou tableaux à 1 dimension) pour leur implantation.
|
||||
|
||||
Chaînes et fichiers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+ traitement des chaines de caractères
|
||||
+ s.replace()
|
||||
+ s1 + s2
|
||||
+ un exemple de regexp simple
|
||||
+ type de fichiers
|
||||
+ mode d'accès
|
||||
+ glob.glob
|
||||
+ Sans doute ces points peuvent être intégrés dans la séance 2.
|
||||
|
||||
+ **Fichiers** :
|
||||
notion de chemin d’accès, lecture et écriture de données numériques ou de type chaîne de caractères depuis ou vers un fichier.
|
||||
On encourage l’utilisation de fichiers en tant que supports de données ou de résultats avant divers traitements, par exemple graphiques.
|
||||
|
||||
manips sur les structures de contrôle de base
|
||||
|
||||
+ écrire des instructions conditionnelles avec alternatives,
|
||||
+ démontrer qu’une boucle se termine effectivement.
|
||||
+ organisation modulaire des programmes
|
||||
+ programmation structurée.
|
||||
+ **Piles**
|
||||
Algorithmes de manipulation : fonctions 'push' et 'pop'. On utilise des listes
|
||||
(ou tableaux à 1 dimension) pour leur implantation.
|
||||
|
|
|
|||
|
|
@ -5,5 +5,6 @@ Annexes
|
|||
:maxdepth: 2
|
||||
|
||||
exercices
|
||||
surete
|
||||
agile
|
||||
scrum
|
||||
|
|
|
|||
|
|
@ -0,0 +1,93 @@
|
|||
Autres outils de sureté d'un programme
|
||||
--------------------------------------
|
||||
|
||||
La preuve de programme
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Le niveau maximum de sûreté d'exécution d'un programme est la preuve. Qu'est-ce que la preuve
|
||||
formelle d'un programme ? Selon la définition de Wikipédia, ce 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." Bref c'est un raisonnement logique sur un programmme qui permet d'être sûr que le
|
||||
programme est valide et ne va pas planter.
|
||||
|
||||
La preuve de programme est très peu utilisée dans l'industrie, car très coûteuse et très
|
||||
difficile à mettre en place. Elle quand même utilisée, mais dans des secteurs où le risque doit
|
||||
absolument être évacué et où il n'y a aucun droit à l'erreur. Par exemple, le secteur médical
|
||||
(informatique en bloc opératoire), militaire (peu d'informations nous parviennent dans ce
|
||||
domaine), l'aviation civile (le logiciel Astrée pour Airbus), la fusée Ariane (depuis le bug qui
|
||||
avait fait crasher Ariane 5 ces questions sont prises très au sérieux), et le milieu bancaire
|
||||
(surtout le domaine des décisions boursières : un programme chargé de lancer des décisions
|
||||
d'achat ou de vente à la bourse qui comporte un bug peut en quelque centièmes de secondes faire
|
||||
perdre des millions, voire des milliards d'euros à une banque. Le programme ne doit tout simplement pas
|
||||
bugger).
|
||||
|
||||
Le model checking
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Le model checking, l'analyse statique et l'interprétation abstraite procèdent d'une méthodologie
|
||||
moins lourde de validation des programmes. Ces méthodes analysent exhaustivement l'évolution du
|
||||
système lors de ses exécutions possibles et permetent de dire si globalement, dans un contexte
|
||||
donné, le programme va fonctionner correctement. Encore très lourdes, ces techniques ne sont
|
||||
utilisées que dans un contexte industriel de haute sécurité.
|
||||
|
||||
Les tests d'acceptation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Il y a plusieurs types de tests
|
||||
|
||||
- unitaires
|
||||
- fonctionnels
|
||||
- acceptation
|
||||
|
||||
Très utilisés dans l'industrie, les tests unitaires et fonctionnels ne testent que certaines
|
||||
parties du programme et permettent de dire que le programme va marcher grosso-modo à peu près.
|
||||
Beaucoup moins coûteux à installer, ce sont des éléments cléfs des méthodes agiles.
|
||||
|
||||
Les Outils de linting (validation)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- vérifications syntaxiques
|
||||
- vérification sémantiques
|
||||
- vérification sur les imports inutiles ou mal formés (imports croisés
|
||||
|
||||
Exemple en python : pylint
|
||||
|
||||
|
||||
La dette technique
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Au bout d'un moment le code devient du code spaghetti et les techniques sont obsolètes.
|
||||
Les tests permettent de solder la dette technique plus facilement.
|
||||
|
||||
**avoir le courage de payer une dette technique, et affronter une dette technique
|
||||
sinon il peut y avoir un coût à payer qui sera pohibitoire.**
|
||||
|
||||
On solde la dette technique parce que à un moment ça va devenir beaucoup trop
|
||||
cher à payer.
|
||||
|
||||
Les méthodologies agiles
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
La manière dont le code est produit importe énormément. Par exemple, une
|
||||
méthodologie ou le **refactoring** (réécriture de code) est permis et même conseillé
|
||||
a plus de chance de produire du code organisé.
|
||||
|
||||
Les méthodologies agiles produisent en général du code mieux organisé. Ce sont les
|
||||
méthodes de travail les plus en vogue aujourd'hui, elles mettent l'accent sur :
|
||||
|
||||
- Du logiciel fonctionnel plutôt que de la documentation exhaustive
|
||||
- La réponse au changement plutôt que le suivi d'un plan
|
||||
- Le logiciel fonctionnel est la principale mesure d'avancement
|
||||
- Une attention continue à l'excellence technique et à une bonne
|
||||
conception améliore l'agilité
|
||||
- La simplicité est essentielle (il est facile de faire, il est
|
||||
difficile de faire simple)
|
||||
|
||||
Le principe de base de la méthodologie Scrum par exemple est de focaliser l'équipe de façon
|
||||
itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une
|
||||
à quatre semaines, appelées **sprints**. Chaque sprint possède un but à atteindre, défini par le
|
||||
responsable de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce
|
||||
sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce
|
||||
temps, le facilitateur a la charge de réduire au maximum les perturbations extérieures et de
|
||||
résoudre les problèmes non techniques de l'équipe.
|
||||
|
|
@ -43,6 +43,73 @@ Algorithme de la longueur d'une liste
|
|||
|
||||
Cette fonction est prédéfinie en Ocaml : `List.length`
|
||||
|
||||
.. ifconfig:: exercice
|
||||
|
||||
**Exercice** : écrire un algorithme qui déclare et
|
||||
remplisse un tableau de 7 valeurs numériques en les mettant toutes à zéro.
|
||||
|
||||
.. ifconfig:: correction
|
||||
|
||||
**Correction** :
|
||||
::
|
||||
|
||||
Tableau Truc(6) en Numérique
|
||||
Variable i en Numérique
|
||||
Debut
|
||||
Pour i <- 0 à 6
|
||||
Truc(i) <- 0
|
||||
i Suivant
|
||||
Fin
|
||||
|
||||
exemple d'implémentation en python
|
||||
|
||||
.. code-block: python
|
||||
|
||||
>>> liste = []
|
||||
>>> for i in range(6):
|
||||
... liste.append(i)
|
||||
...
|
||||
>>> liste
|
||||
[0, 1, 2, 3, 4, 5]
|
||||
>>>
|
||||
|
||||
.. glossary::
|
||||
|
||||
Matrice
|
||||
|
||||
Tableaux de dimension multiple, c'est un tableau de tableau
|
||||
|
||||
.. ifconfig:: exercice
|
||||
|
||||
**Exercice** : Écrivez un algorithme remplissant un tableau de 6 sur 13, avec des zéros.
|
||||
|
||||
.. ifconfig:: correction
|
||||
|
||||
**Correction** :
|
||||
|
||||
implémentation en python
|
||||
|
||||
.. code-block: python
|
||||
|
||||
>>> matrice = []
|
||||
>>> for i in range(12):
|
||||
... matrice.append([0 for i in range(5)])
|
||||
...
|
||||
>>> from pprint import pprint
|
||||
>>> pprint(matrice)
|
||||
[[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0],
|
||||
[0, 0, 0, 0, 0]]
|
||||
>>>
|
||||
|
||||
Algorithmes de tri
|
||||
------------------
|
||||
|
|
@ -59,6 +126,7 @@ Tri par insertion
|
|||
|
||||
Cet algorithme de tri suit de manière naturelle la structure récursive des
|
||||
listes. Soit l une liste à trier :
|
||||
|
||||
- si l est vide alors elle est déjà triée
|
||||
- sinon, l est de la forme x::s et on trie récursivement la suite s et on obtient une liste triée s’
|
||||
on insert x au bon endroit dans s’ et on obtient une liste triée
|
||||
|
|
|
|||
|
|
@ -100,97 +100,6 @@ valider
|
|||
La validation va de la série de tests unitaires (validation faible)
|
||||
à la preuve de programme (validation mathématique forte).
|
||||
|
||||
La preuve de programme
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Le niveau maximum de sûreté d'exécution d'un programme est la preuve. Qu'est-ce que la preuve
|
||||
formelle d'un programme ? Selon la définition de Wikipédia, ce 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." Bref c'est un raisonnement logique sur un programmme qui permet d'être sûr que le
|
||||
programme est valide et ne va pas planter.
|
||||
|
||||
La preuve de programme est très peu utilisée dans l'industrie, car très coûteuse et très
|
||||
difficile à mettre en place. Elle quand même utilisée, mais dans des secteurs où le risque doit
|
||||
absolument être évacué et où il n'y a aucun droit à l'erreur. Par exemple, le secteur médical
|
||||
(informatique en bloc opératoire), militaire (peu d'informations nous parviennent dans ce
|
||||
domaine), l'aviation civile (le logiciel Astrée pour Airbus), la fusée Ariane (depuis le bug qui
|
||||
avait fait crasher Ariane 5 ces questions sont prises très au sérieux), et le milieu bancaire
|
||||
(surtout le domaine des décisions boursières : un programme chargé de lancer des décisions
|
||||
d'achat ou de vente à la bourse qui comporte un bug peut en quelque centièmes de secondes faire
|
||||
perdre des millions, voire des milliards d'euros à une banque. Le programme ne doit tout simplement pas
|
||||
bugger).
|
||||
|
||||
Le model checking
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Le model checking, l'analyse statique et l'interprétation abstraite procèdent d'une méthodologie
|
||||
moins lourde de validation des programmes. Ces méthodes analysent exhaustivement l'évolution du
|
||||
système lors de ses exécutions possibles et permetent de dire si globalement, dans un contexte
|
||||
donné, le programme va fonctionner correctement. Encore très lourdes, ces techniques ne sont
|
||||
utilisées que dans un contexte industriel de haute sécurité.
|
||||
|
||||
Les tests d'acceptation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Il y a plusieurs types de tests
|
||||
|
||||
- unitaires
|
||||
- fonctionnels
|
||||
- acceptation
|
||||
|
||||
Très utilisés dans l'industrie, les tests unitaires et fonctionnels ne testent que certaines
|
||||
parties du programme et permettent de dire que le programme va marcher grosso-modo à peu près.
|
||||
Beaucoup moins coûteux à installer, ce sont des éléments cléfs des méthodes agiles.
|
||||
|
||||
Les Outils de linting (validation)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- vérifications syntaxiques
|
||||
- vérification sémantiques
|
||||
- vérification sur les imports inutiles ou mal formés (imports croisés
|
||||
|
||||
Exemple en python : pylint
|
||||
|
||||
|
||||
La dette technique
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Au bout d'un moment le code devient du code spaghetti et les techniques sont obsolètes.
|
||||
Les tests permettent de solder la dette technique plus facilement.
|
||||
|
||||
**avoir le courage de payer une dette technique, et affronter une dette technique
|
||||
sinon il peut y avoir un coût à payer qui sera pohibitoire.**
|
||||
|
||||
On solde la dette technique parce que à un moment ça va devenir beaucoup trop
|
||||
cher à payer.
|
||||
|
||||
Les méthodologies agiles
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
La manière dont le code est produit importe énormément. Par exemple, une
|
||||
méthodologie ou le **refactoring** (réécriture de code) est permis et même conseillé
|
||||
a plus de chance de produire du code organisé.
|
||||
|
||||
Les méthodologies agiles produisent en général du code mieux organisé. Ce sont les
|
||||
méthodes de travail les plus en vogue aujourd'hui, elles mettent l'accent sur :
|
||||
|
||||
- Du logiciel fonctionnel plutôt que de la documentation exhaustive
|
||||
- La réponse au changement plutôt que le suivi d'un plan
|
||||
- Le logiciel fonctionnel est la principale mesure d'avancement
|
||||
- Une attention continue à l'excellence technique et à une bonne
|
||||
conception améliore l'agilité
|
||||
- La simplicité est essentielle (il est facile de faire, il est
|
||||
difficile de faire simple)
|
||||
|
||||
Le principe de base de la méthodologie Scrum par exemple est de focaliser l'équipe de façon
|
||||
itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une
|
||||
à quatre semaines, appelées **sprints**. Chaque sprint possède un but à atteindre, défini par le
|
||||
responsable de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce
|
||||
sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce
|
||||
temps, le facilitateur a la charge de réduire au maximum les perturbations extérieures et de
|
||||
résoudre les problèmes non techniques de l'équipe.
|
||||
|
||||
Conception descendante
|
||||
-----------------------
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue