Complexité de programmation - Programming complexity

La complexité de la programmation (ou complexité logicielle ) est un terme qui inclut de nombreuses propriétés d'un logiciel, qui affectent toutes les interactions internes. Selon plusieurs commentateurs, il y a une distinction entre les termes complexe et compliqué. Compliqué implique d'être difficile à comprendre mais avec du temps et des efforts, finalement connaissable. Complexe, quant à lui, décrit les interactions entre un certain nombre d'entités. Au fur et à mesure que le nombre d'entités augmente, le nombre d'interactions entre elles augmenterait de façon exponentielle, et il en arriverait à un point où il serait impossible de toutes les connaître et de les comprendre. De même, des niveaux de complexité plus élevés dans les logiciels augmentent le risque d'interférer involontairement avec les interactions et augmentent ainsi le risque d'introduire des défauts lors des modifications. Dans des cas plus extrêmes, cela peut rendre la modification du logiciel pratiquement impossible. L'idée de lier la complexité du logiciel à la maintenabilité du logiciel a été largement explorée par le professeur Manny Lehman , qui a développé ses lois de l'évolution du logiciel à partir de ses recherches. Lui et son co-auteur Les Belady ont exploré de nombreuses métriques logicielles possibles dans leur livre souvent cité, qui pourraient être utilisées pour mesurer l'état du logiciel, aboutissant finalement à la conclusion que la seule solution pratique serait d'en utiliser une qui utilise la complexité déterministe. des modèles.

Les mesures

De nombreuses mesures de la complexité des logiciels ont été proposées. Beaucoup d'entre eux, bien que donnant une bonne représentation de la complexité, ne se prêtent pas à une mesure facile. Certaines des mesures les plus couramment utilisées sont

Métrique de complexité cyclomatique de McCabe
Métriques de la science du logiciel Halsteads
Henry et Kafura ont introduit les métriques de structure logicielle basées sur le flux d'informations en 1981, qui mesurent la complexité en fonction de l'entrée et de la sortie. Ils définissent le fan-in d'une procédure comme le nombre de flux locaux dans cette procédure plus le nombre de structures de données à partir desquelles cette procédure extrait des informations. La fan-out est définie comme le nombre de flux locaux sortant de cette procédure plus le nombre de structures de données que la procédure met à jour. Les flux locaux concernent les données transmises vers et depuis les procédures qui appellent ou sont appelées par la procédure en question. La valeur de complexité de Henry et Kafura est définie comme "la longueur de la procédure multipliée par le carré de la sortie multipliée par la sortie" (Longueur × (sortie × sortie) ²).
Une suite de métriques pour la conception orientée objet a été introduite par Chidamber et Kemerer en 1994 en se concentrant, comme le titre l'indique, sur les métriques spécifiquement pour le code orienté objet. Ils introduisent six métriques de complexité OO; méthodes pondérées par classe, couplage entre classes d'objets, réponse pour une classe, nombre d'enfants, profondeur de l'arbre d'héritage et manque de cohésion des méthodes

Il existe plusieurs autres métriques qui peuvent être utilisées pour mesurer la complexité de la programmation:

Complexité de branchement (métrique Sneed)
Complexité de l'accès aux données (métrique de la carte)
Complexité des données (Chapin Metric)
Complexité du flux de données (métrique Elshof)
Complexité décisionnelle (McClure Metric)

La loi de Tesler est un adage dans l'interaction homme-ordinateur déclarant que chaque application a une complexité inhérente qui ne peut pas être supprimée ou masquée.

Les types

La complexité associée au changement de programme est associée et dépendante de la complexité d'un programme existant. La complexité d'un problème peut être divisée en deux parties:

Complexité accidentelle: se rapporte aux difficultés auxquelles un programmeur est confronté en raison des outils de génie logiciel choisis. Un ensemble d'outils mieux adapté ou un langage de programmation de plus haut niveau peut le réduire. La complexité accidentelle est souvent aussi une conséquence de l'absence d'utilisation du domaine pour encadrer la forme de la solution, c'est-à-dire le code. Une pratique qui peut aider à éviter la complexité accidentelle est la conception axée sur le domaine .
Complexité essentielle: elle est causée par les caractéristiques du problème à résoudre et ne peut être réduite.

Métriques Chidamber et Kemerer

Chidamber et Kemerer ont proposé un ensemble de métriques de complexité de programmation, largement utilisées dans de nombreuses mesures et articles académiques. Il s'agit de WMC, CBO, RFC, NOC, DIT et LCOM, décrits ci-dessous:

WMC - méthodes pondérées par classe
- ${\ displaystyle WMC = \ sum _ {i = 1} ^ {n} c_ {i}}$
- n est le nombre de méthodes sur la classe
- ${\ displaystyle c_ {i}}$ est la complexité de la méthode
CBO - couplage entre classes d'objets
- nombre d'autres classes couplées (utilisant ou étant utilisées)
RFC - réponse pour une classe
- ${\ displaystyle RFC = | RS |}$ où
- ${\ displaystyle RS = \ {M \} \ cup _ {all \ i} \ {R_ {i} \}}$
- ${\ displaystyle R_ {i}}$ est un ensemble de méthodes appelées par la méthode i
- ${\ displaystyle M}$ est l'ensemble des méthodes de la classe
NOC - nombre d'enfants
- somme de toutes les classes qui héritent de cette classe ou d'un descendant de celle-ci
DIT - profondeur de l'arbre d'héritage
- profondeur maximale de l'arbre d'héritage pour cette classe
LCOM - manque de cohésion des méthodes
- Mesure l'intersection des attributs utilisés en commun par les méthodes de classe
- ${\ displaystyle LCOM = {\ begin {cases} | P | - | Q |, & {\ text {if}} | P |> | Q | \\ 0, & {\ text {sinon}} \ end {cases }}}$
- Où ${\ displaystyle P = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} = \ emptyset \}}$
- Et ${\ displaystyle Q = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} \ neq \ emptyset \}}$
- Avec est l'ensemble des attributs (variables d'instance) accédés (en lecture ou en écriture) par la -th méthode de la classe ${\ displaystyle I_ {i}}$ ${\ displaystyle i}$