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



