formations/algorithmique/cours/modularite.txt

L'organisation d'un programme
=============================


Un langage de programmation doit permettre la programmation structurée.

.. important:: La structuration et l'organisation modulaire sert à maintenir de grands programmes,
               Elles sont une nécessité

Structuration d'un programme
-----------------------------

La réalisation d'applications importantes oblige le programmeur ou l'équipe de
développement à se poser des questions d'organisation et de structuration.
Aujourd'hui, on dispose de deux grands modèles d'organisation dont les avantages et les
particularités sont distincts.

La modularité
~~~~~~~~~~~~~

Les données et les traitements sont regroupés au sein d'une même entité à deux
facettes : d'un côté le code proprement dit, de l'autre son interface. La
communication entre modules s'effectue via leur interface. La description d'un
type peut être masquée en n'apparaissant pas dans l'interface du module. Ces
types de données abstraits facilitent les modifications d'implantation à
l'intérieur d'un module sans affecter les autres modules qui s'en servent. De
plus, les modules peuvent être paramétrés par d'autres modules augmentant
ainsi leur réutilisabilité.

Le paradigme objet
~~~~~~~~~~~~~~~~~~

Les descriptions des traitements et des données sont regroupées dans des
entités appelées **classes**; un objet est une instance (valeur) d'une classe.
La communication entre objets est réalisée par envoi de message, l'objet
receveur détermine à l'exécution (liaison retardée) le traitement
correspondant au message. En cela, la programmation objet est dirigée par
les données. La structuration d'un programme provient des relations entre
classes, en particulier l'héritage permet de définir une classe par extension
d'une autre.

En programmation objet, un **programme** est une collection d’objets qui communiquent
entre eux par **message**, le **résultat** est un message envoyé à un objet particulier

Comparaison entre les deux paradigmes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Il y a dualité entre ces deux modèles.

- On ne peut pas augmenter les composants d'un type dans un module (pas
  d'extensibilité des données), mais on peut ajouter de nouveaux traitements
  (extensibilité des traitements) sur ces données.

- En objet, on peut ajouter des sous-classes à une classe (extensibilité des
  données) pour traiter des nouveaux cas, mais on ne peut pas ajouter de nouveaux
  traitements visibles de la classe ancêtre (pas d'extensibilité des traitements).

**La combinaison des deux paradigmes offre de nouvelles extensibilités pour les
traitements et les données.**

Structuration et sûreté d'exécution
-----------------------------------

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
~~~~~~~~~~~~~~~~~~~~~~~

C'est sont les tests unitaires et fonctionnels


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.


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.


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

Les modules
-----------

Il s'agit de décomposer un grand programme en
morceaux (**modules**) connectés entre eux par des **interfaces** bien
définies.

Ces modules doivent être aussi indépendants que possible.

module

    ensemble de ressources  liées sémantiquement

interface

    mode d’emploi du module

Les interfaces

- principe de masquage des informations (partie publique, partie secrète)