From 51a9d99d78565a38c328341ceed7453ac9b90da2 Mon Sep 17 00:00:00 2001 From: Yorick Barbanneau Date: Wed, 17 Apr 2024 22:04:11 +0200 Subject: [PATCH] feat: add software architecture principes --- .../projet_programmation/8_principes/index.md | 84 +++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 content/projet_programmation/8_principes/index.md diff --git a/content/projet_programmation/8_principes/index.md b/content/projet_programmation/8_principes/index.md new file mode 100644 index 0000000..687a87a --- /dev/null +++ b/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). + + +