feat: add software architecture principes

content/projet_programmation/8_principes/index.md

@@ -0,0 +1,84 @@
+---
+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).
+
+
+