Métriques de code - Couplage de classes

Le couplage de classes est également nommé « couplage entre objets » (CBO, Coupling Between Objects) comme défini à l’origine par CK94. Fondamentalement, le couplage de classes est une mesure du nombre de classes utilisées par une seule classe. Il est généralement préférable que cette métrique présente une valeur faible (une valeur élevée n’est pas une bonne chose). Il a été démontré que le couplage de classes permet de prédire avec précision les défaillances logicielles. En outre, des études récentes ont montré qu’une valeur limite supérieure de 9 offre la meilleure efficacité (S2010).

Selon la documentation Microsoft, le couplage de classes « mesure le couplage avec des classes uniques via des paramètres, des variables locales, des types de retour, des appels de méthodes, des instanciations génériques ou de modèles, des classes de base, des implémentations d'interfaces, des champs définis sur des types externes et une décoration d'attributs. Une bonne conception logicielle détermine 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 ne pas nous éloigner du thème principal de cet article, nous n’aborderons pas la cohésion en détail. Nous nous en tiendrons à une brève définition fournie par KKLS2000 :

« La cohésion des modules a été présentée par Yourdon et Constantine comme la « mesure dans laquelle les éléments internes d'un module sont étroitement liés ou associés les uns aux autres » (YC79). Un module a une forte cohésion s'il représente exactement une tâche [...], et si tous ses éléments contribuent à cette seule tâche. Ils décrivent la cohésion comme un attribut de conception et non comme du code ; un attribut qui peut être utilisé pour prédire la réutilisabilité, la maintenabilité et la capacité de 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 contenant quelques propriétés, puis calculez immédiatement les métriques de code :

Notez que le couplage de classes a la valeur 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 :

Vous voyez que la valeur du couplage de classes a augmenté. Notez également que, quel que soit le nombre de propriétés que vous définissez, la valeur du couplage de classes augmente de 1 unité (et de 1 unité seulement). Le couplage de classes ne mesure chaque classe qu’une seule fois pour cette métrique, quelle que soit la quantité de code qui l’utilise. En outre, pouvez-vous voir que DoSomething() a la valeur 1, mais que le constructeur PersonStuff() a la valeur 0. Actuellement, aucun code dans le constructeur n’utilise une autre classe.

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

Maintenant, le constructeur a clairement du code qui utilise une autre classe, ce qui se reflète dans la métrique de couplage de classes. Là encore, vous pouvez voir que le couplage de classes global pour PersonStuff() a la valeur 1, tout comme DoSomething(). Ceci montre qu’une seule classe externe est utilisée, quelle que soit la quantité de code interne qui l’utilise.

Créez ensuite une autre classe. Donnez-lui un nom et créez quelques propriétés dans la classe :

Maintenant, consommez la classe dans la méthode DoSomething() au sein de la classe PersonStuff et calculez à nouveau les métriques de code :

Comme vous pouvez le voir, le couplage de classes pour la classe PersonStuff atteint la valeur 2 et, si vous explorez la classe, vous pouvez voir que la méthode DoSomething() présente le couplage le plus élevé, alors que le constructeur consomme toujours une seule classe. Avec ces métriques, vous pouvez voir le nombre maximal global d’une classe donnée et explorer les détails par membre.

Nombre magique

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

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

Analyse du code

L’analyse du code inclut une catégorie de règles de maintenabilité. Pour plus d’informations, consultez Règles de maintenabilité. Quand vous utilisez une analyse du code héritée, l’ensemble de règles Extended Design Guideline inclut une catégorie de maintenabilité :

La catégorie de maintenabilité inclut une règle pour le couplage de classes :

Cette règle émet un avertissement quand le couplage de classes est excessif. Pour plus d’informations, consultez CA1506 : Éviter les couplages de classes excessifs.

Références

CK94

Chidamber, S. R. et Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, N° 6). Extrait le 14 mai 2011 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). Class Cohesion Revisited: An Empirical Study on Industrial Systems (Proceedings of the Workshop on Quantitative Approaches in Object-Oriented Software Engineering). Extrait le 20 mai 2011 du site web de l’Université de Montréal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. et Krishnan, M. S. (2003). Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects (IEEE Transactions on Software Engineering, Vol. 29, N° 4).

S2010

Shatnawi, R. (2010). A Quantitative Investigation of the Acceptable Risk Levels of Object-Oriented Metrics in Open-Source Systems (IEEE Transactions on Software Engineering, Vol. 36, N° 2).

YC79

Edward Yourdon et Larry L. Constantine. Structured Design. Prentice Hall, Englewood Cliffs, N.J., 1979.