175 lines
7.5 KiB
Plaintext
175 lines
7.5 KiB
Plaintext
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)
|