3.4 KiB
| title | date | tags | categories | |||||
|---|---|---|---|---|---|---|---|---|
| PdP: Les principes | 2024-03-21 |
|
|
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,publicprivate,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).