content/projet_programmation/8_principes/index.md

@@ -1,84 +0,0 @@
----
-title: "PdP: Les principes"
-date: 2024-03-21
-tags: ["besoins", "UML", "developpement logiciel"]
-categories: ["Projet de programmation", "Cours"]
----
-
-Pour rappel, une architecture logicielle est une structure qui permet de
-maîtriser la taille et la complexité du logiciel tout en facilitant son
-évolution. Nous sommes toujours dans l'optique de **décomposer pour maîtriser 
-et transformer**.
-
-Nous devons toujours:
-
- * favoriser la définition de dépendances avec une taille minimale;
- * limiter les dépendances qui diffusent des changements (dépendances à 
-   diffusion minimisé);
- * favoriser la construction de niveau de granularité homogènes donnant lieur à
-   des graphes de dépendances distincts (niveau homogène de granularité);
- * faire en sorte que dans sas suite de granularité, chacun des graphes de
-   dépendances correspondant soit plus simple que le précédent (simplification
-   entre niveaux consécutifs)
- * favoriser la cohésion la plus forte et le couplage le plus faible (min-max);
- * la validité des dépendances entre composants peut se contrôler en les
-   exprimant en langue naturelle de façon logique et intelligible (s'ennoncer
-   clairement).
-
-## Principe de simplicité
-
-Il faut favoriser la simplicité **dans tous ses aspects** et ainsi éviter toute
-complexité. L;appellation la plus connue est *KISS* pour *Keep It Stupidly.
-Simple*.
-
-Ce principe implique :
-
- * pas de construction qui ne couvre pas un besoin identifié;
- * pas d'implémentation d'un besoin non fonctionnel non justifié;
- * pas de généralité ou de généricité sans nécessité.
-
- Le principe de Peter en logiciel : tenter d'améliorer, de généraliser un
- programme au delà des limites ses connaissances tel qu'il devienne
- incompréhensible. Celui-ci va à l'encontre du principe *KISS*, il va dans le
- même sens de l'effet de *Dunning-Krueger* : la situation où une personne
- surestime sa compétence, mais aussi est trop incompétente pour comprendre sa
- propre incompétence.
-
-## Principe de non duplication
-
-Il faut éviter d'inclure de la duplication non seulement de  code mais aussi de
-données, de représentation, de sous-structures de composants, de documentation
-etc. Ces duplications sont difficilement maintenables et allongent inutilement le
-code.
-
-Ces duplications peuvent avoir plusieurs sources:
-
- * négligence des développeurs qui peuvent dupliquer par facilité et/ou
-   rapidité;
- * développeurs qui dupliquent du codes chacun de son côté sans s'en rendre
-   compte;
- * les circonstances imposent une duplication de code (standards, formats ...);
- * par inadvertance, lorsque les développeurs n'ont pas conscience de dupliquer.
-
-Dans le dernier cas, c'est sûrement que les dépendances entre les éléments n'ont
-pas été identifié.
-
-Ces duplications doivent être factorisées, on les remplacent alors pas des
-définitions, des fonctions/procédures, des mécanismes de généricité.
-
-### Cloisonnement et masquage
-
-Dans une architecture logicielle, les composants ne doivent laisser qu'un
-minimum de leurs éléments visibles ou public tout en préservant le
-fonctionnement général.
-
- * Règles implicites du *public*/*privé*.
- * Directives explicites *public*/*privé* sur les composants (`extern`, `public`
-   `private`, `static`, ...)
- * Utilisation d'interface.
-
-Ce principe est parfois difficile à appliquer notamment quant au choix de la
-localisation des éléments (coucou principe de simplification min-max).
-
-
-