Cohésion (informatique)

La cohésion est un principe de conception informatique définissant un degré d'accord entre les différents éléments d'un module. Selon Larman[1], un module cohérent a ses éléments étroitement liés et effectuant un nombre réduit d'opérations. Des modules peu cohérents sont généralement difficiles à comprendre, à réutiliser et à maintenir, et sont fragiles, puisqu'ils sont affectés par les modifications apportées aux autres modules.

La cohésion peut être une métrique mesurant l'application des principes d'encapsulation des données et de masquage de l'information. Elle mesure également la cohésion sémantique des interfaces des modules et des classes.

Niveaux de cohésion

modifier

Selon Pressman[2], il existe sept niveaux de cohésion :

  1. Accidentel : décrivant le niveau le plus faible où le lien entre les différentes méthodes est inexistant ou bien créé sur la base d'un critère futile.
  2. Logique : lorsque les méthodes sont reliées logiquement par un ou plusieurs critères communs.
  3. Temporel : lorsque les méthodes doivent être appelées au cours de la même période de temps.
  4. Procédural : lorsque les méthodes doivent être appelées dans un ordre spécifique.
  5. Communicationnel : lorsque les méthodes manipulent le même ensemble spécifique de données.
  6. Séquentiel : lorsque les méthodes qui manipulent le même ensemble de données doivent être appelées dans un ordre spécifique.
  7. Fonctionnel : réalise le niveau le plus élevé lorsque la classe ou le module est dédié à une seule et unique tâche bien spécifique.

Le niveau accidentel est celui de plus faible cohésion, le niveau fonctionnel celui de plus forte cohésion ; une bonne architecture logicielle nécessite la plus forte cohésion possible.

Implémentation

modifier

En programmation objet, le respect des principes d'encapsulation des données permet d'obtenir le niveau de cohésion communicationnel. Le niveau séquentiel est atteint par observation du principe de masquage de l'information et l'utilisation de patrons de conception reconnus qui permettent de créer des interfaces dont l'ordre des appels est normalisé (vous en connaissez une, vous les connaissez toutes). Le niveau fonctionnel est ici un idéal, rappelant sans cesse que moins une interface contient de méthodes, plus elle est simple à utiliser.

Voir aussi

modifier

Notes et références

modifier
  1. Larman C., UML 2 et les design patterns. Troisième édition. Pearson Éducation. Chapitre 16, 2005
  2. Pressman R. S., Software Engineering : A Practitioner's Approach, Third Edition. McGraw-Hill. Chapitre 10, 1992