84 lines
3.4 KiB
Markdown
84 lines
3.4 KiB
Markdown
---
|
|
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).
|
|
|
|
|
|
|