Métriques de code - Couplage de classes

Le couplage de classes passe également par le nom Couplage entre les objets (CBO) tel qu’initialement défini par CK94. En fait, le couplage de classes est une mesure du nombre de classes qu’une classe utilise. Un nombre élevé est incorrect et un nombre faible est généralement bon avec cette métrique. Le couplage de classes a été démontré comme un prédicteur précis des défaillances logicielles et des études récentes ont montré qu’une valeur limite supérieure de 9 est la plus efficace S2010.

Selon la documentation Microsoft, le couplage de classes « mesure le couplage à des classes uniques par le biais de paramètres, de variables locales, de types de retour, d’appels de méthode, d’instanciations génériques ou de modèles, de classes de base, d’implémentations d’interface, de champs définis sur des types externes et de la décoration d’attributs. Une bonne conception logicielle dicte que les types et méthodes doivent avoir une cohésion élevée et un couplage faible. Le couplage élevé indique une conception difficile à réutiliser et à maintenir en raison de ses nombreuses interdépendances sur d’autres types.

Les concepts de couplage et de cohésion sont clairement liés. Pour garder cette discussion sur le sujet, nous n’allons pas entrer en profondeur avec la cohésion autre que pour donner une brève définition de KKLS2000 :

« La cohésion du module a été introduite par Yourdon et Constantine comme la manière dont les éléments internes d’un module sont étroitement liés entre eux YC79. » Un module a une forte cohésion s’il représente exactement une tâche [...], et tous ses éléments contribuent à cette tâche unique. Ils décrivent la cohésion comme un attribut de conception, plutôt que du code, et un attribut qui peut être utilisé pour prédire la réutilisation, la facilité de maintenance et la modification.

Exemple de couplage de classes

Examinons le couplage de classes en action. Tout d’abord, créez une application console et créez une classe appelée Person avec certaines propriétés dans celle-ci, puis calculez immédiatement les métriques de code :

Notez que le couplage de classes est 0, car cette classe n’utilise aucune autre classe. Créez maintenant une autre classe appelée PersonStuff avec une méthode qui crée une instance de Person et définit les valeurs de propriété. Calculez à nouveau les métriques de code :

Voyez comment la valeur de couplage de classe augmente ? Notez également que, quel que soit le nombre de propriétés que vous définissez, la valeur de couplage de classe monte simplement de 1 et non par une autre valeur. Le couplage de classes mesure chaque classe une seule fois pour cette métrique, quelle que soit la quantité utilisée. En outre, pouvez-vous voir que DoSomething() a une valeur de 1, mais le constructeur, PersonStuff(), a pour valeur 0 ? Actuellement, il n’existe aucun code dans le constructeur qui utilise une autre classe.

Que se passe-t-il si vous placez du code dans le constructeur qui a utilisé une autre classe ? Voici ce que vous obtenez :

Maintenant, le constructeur a clairement du code qui utilise une autre classe et la métrique de couplage de classe montre ce fait. Encore une fois, vous pouvez voir que le couplage global de la classe pour PersonStuff() est de 1 et DoSomething() est également de 1, indiquant qu'une seule classe externe est utilisée, quelle que soit la quantité de code interne que vous avez qui l'utilise.

Ensuite, créez une autre classe. Donnez à cette classe un nom et créez des propriétés à l’intérieur de celle-ci :

Utilisez maintenant la classe dans notre DoSomething() méthode dans la PersonStuff classe et calculez à nouveau les métriques de code :

Comme vous pouvez le voir, le couplage de la classe PersonStuff atteint le niveau 2 et, si vous explorez la classe, vous pouvez voir que la méthode DoSomething() présente le plus fort couplage, mais le constructeur ne consomme toujours qu'une classe. À l’aide de ces métriques, vous pouvez voir le nombre maximal global d’une classe donnée et explorer les détails par membre.

Le numéro magique

Comme avec la complexité cyclomatique, il n’existe aucune limite qui correspond à toutes les organisations. Toutefois, S2010 indique qu’une limite de 9 est optimale :

« Par conséquent, nous considérons les valeurs de seuil [...] comme le plus efficace. Ces valeurs de seuil (pour un seul membre) sont CBO = 9[...]. » (accentuation ajoutée)

Analyse du code

L’analyse du code comprend une catégorie de règles de maintenance. Pour plus d’informations, consultez règles de maintenance. Lors de l’utilisation de l’analyse du code hérité, l’ensemble de règles de recommandations de conception étendue contient une zone de facilité de maintenance :

Dans la zone de maintenabilité, il y a une règle concernant le couplage de classes :

Cette règle émet un avertissement lorsque le couplage de classe est excessif. Pour plus d’informations, consultez CA1506 : Éviter un couplage de classe excessif.

Références

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). Une suite metrics pour la conception orientée objet (transactions IEEE sur l’ingénierie logicielle, vol. 20, no 6). Récupéré le 14 mai 2011, à partir du site web de l’Université de Pittsburgh : http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F. et Saint-Denis, G. (2000). Cohésion de classe revisitée : étude empirique sur les systèmes industriels (Actes de l’atelier sur les approches quantitatives dans l’ingénierie logicielle orientée objet). Récupéré le 20 mai 2011 à partir du site web de l’Université de Montréal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Krishnan, M. S. (2003). Analyse empirique des métriques CK pour la complexité de conception orientée objet : implications pour les défauts logiciels (Transactions IEEE sur l'Ingénierie Logicielle, vol. 29, n° 4).

S2010

Shatnawi, R. (2010). Examen quantitatif des niveaux de risque acceptables des métriques orientées objet dans les systèmes open source (Transactions IEEE sur l’ingénierie logicielle, vol. 36, n° 2).

YC79

Edward Yourdon et Larry L. Constantine. Conception structurée. Prentice Hall, Englewood Cliffs, N.J., 1979.