diff --git a/algorithmique/cours/annexes/exercices.txt b/algorithmique/cours/annexes/exercices.txt index 8a910f8..22f6047 100644 --- a/algorithmique/cours/annexes/exercices.txt +++ b/algorithmique/cours/annexes/exercices.txt @@ -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. diff --git a/algorithmique/cours/annexes/index.txt b/algorithmique/cours/annexes/index.txt index 566502a..dc5acf1 100644 --- a/algorithmique/cours/annexes/index.txt +++ b/algorithmique/cours/annexes/index.txt @@ -5,5 +5,6 @@ Annexes :maxdepth: 2 exercices + surete agile scrum diff --git a/algorithmique/cours/annexes/surete.txt b/algorithmique/cours/annexes/surete.txt new file mode 100644 index 0000000..2b275f0 --- /dev/null +++ b/algorithmique/cours/annexes/surete.txt @@ -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. diff --git a/algorithmique/cours/donnees.txt b/algorithmique/cours/donnees.txt index 9a1fcb2..1d8c7ef 100644 --- a/algorithmique/cours/donnees.txt +++ b/algorithmique/cours/donnees.txt @@ -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 diff --git a/algorithmique/cours/modularite.txt b/algorithmique/cours/modularite.txt index 075a128..a729448 100644 --- a/algorithmique/cours/modularite.txt +++ b/algorithmique/cours/modularite.txt @@ -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 -----------------------