formations/algo/algorithmique/cours/modularite.txt

La programmation structurée
=============================

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.

L'écriture des vrais programmes consiste à les structurer pour les présenter
comme un assemblage de briques qui s'emboîtent naturellement.
Ce problème se révèle fondamental dès que la taille des programmes devient conséquente.
Si on ne prend pas garde au bon découpage des programmes en modules indépendants,
on se retrouve rapidement débordé par un grand nombre de variables,
et il devient quasiment impossible de réaliser un programme correct.

La programmation raisonnée
---------------------------

Un **programme** est le codage d'un algorithme dans un langage de programmation.
La programmation consiste à modéliser un problème du monde réel sous une forme
symbolique (pour faire résoudre ce problème par un ordinateur).

Certains problèmes sont **indécidables** ou **ouverts**.
On utilise un langage de programmation pour décrire la **solution** du programme.
La sémantique du programme est le sens de chacune des constructions du langage.
**Comment passer de l'énoncé d'un problème à un programme de bonne qualité ?**

spécifier

    décrire de manière complète et rigoureuse le problème à résoudre

modéliser

    proposer une représentation du réel qui soit accessible au calcul
    algorithmique

transcrire

    La transcription du modèle algorithmique se fait dans un langage
    de programmation cible adapté au problème

valider

    La validation du programme est une étape qui permet de s'assurer plus ou
    moins fortement que le programme produit les résultats attendus.
    La validation va de la série de tests unitaires (validation faible)
    à la preuve de programme (validation mathématique forte).

Conception descendante
-----------------------

Une vision **centripète** : du général au particulier.

Il s'agit d'une méthode de résolution d'un problème. On le découpe en tâches
de plus en plus fines, de plus en plus détaillées, qui aboutiront au programme final.

On met des *trous* dans les algorithmes de plus haut niveau,
c'est-à-dire des phrases en langage naturel.

.. ifconfig:: exercice

    **Exercice** : **Calculer la date du lendemain**

.. ifconfig:: correction

    - l'algorithme de plus haut niveau

    ::

      lendemain jour =
        si jour [est le dernier jour du mois du dernier mois de l'année] alors
          resultat = [calculer le 1er janvier de l'année suivante]
        sinon
          resultat = lendemain_dansl_année(jour)

    - les algorithmes de plus bas niveau associés

    ::

      lendemain_dans_l_année(jour) =
        si jour [est le dernier jour du mois] alors
          resultat = [calculer le premier jour du mois suivant]
        sinon
          resultat = jour_suivant(jour)

    ::

      jour_suivant(jour) =
        jour + 1

    et ainsi de suite jusqu'à ce que toutes les phrases soient calculables.

Algorithme vague
--------------------

L'algorithme vague, c'est quand on pense l'algorithme en se plaçant du côté de
l'implémentation en premier. On a le nez dans le guidon, la vue d'ensemble est
difficile.

Voici, tiré du monde réel, un exemple d'algorithme vague
("ce que doit faire une fonction"), placé dans un bout de code
(souvent la **docstring** d'une fonction).

.. code-block:: python

    def upsert_route(*args, **kwargs):
         """
         Create or modify an existant DHCP route
         param tuple (id or null, machine name, IP, MAC Adress)
         return True or False with error message
         """
         # si id présent alors modification sinon ajout
         # récupère la liste des réservations en cours
         # y cherche la variable sur la base de l'ID
         # modifie les valeurs
         # applique la nouvelle conf DHCP

         return True

Voici un autre bout de code avec l'algorithme en commentaire,
et l'implémentation effective de l'algorithme

.. code-block:: python

     def del_route(*args, **kwargs):
         """
         Delete an existant DHCP route
         param tuple (id, machine name, IP, MAC Adress)
         return True or False with error message
         """
         # récupère la liste des réservations en cours
         # y cherche la variable sur l'id donné en paramètre
         # supprime l'entrée avec vérification que les données fournies
         # sont bien dans l'enregistrement à supprimer
         # applique la nouvelle conf DHCP
         route_to_del = (1, "host2","10.1.2.4","6E:FF:56:A2:AF:17")
         routes = get_routes()
         if route_to_del in routes:
             c = creole_loader(load_extra=True, rw=True)
             c_id = c.dhcp.dhcp.id_dhcp.id_dhcp.index(route_to_del[0])
             if c.dhcp.dhcp.id_dhcp.macaddress[c_id]==route_to_del[2]
                 and c.dhcp.dhcp.id_dhcp.ip[c_id]==route_to_del[1]:
                 c.dhcp.dhcp.id_dhcp.id_dhcp.pop(c_id)
                 config_save_values(c, MODNAME)
                 return True
         return False

Les deux grands paradigmes
---------------------------

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.**