Liens entre deux modules

Nous nous concentrons maintenant sur les liens existant entre deux modules: nous allons examiner quelles en sont les caractéristiques importantes.

Les dépendances entre deux modules sont caractérisées par le type des liens qui les relient, le type d'information qu'ils échangent et le volume d'informations échangées.

Couplage et cohésion

Dans le chapitre précédent, nous avons présenté les différents types de couplage et de cohésion. Nous nous sommes rendus compte de la difficulté à réaliser un outil qui automatise leur identification.

Si l'on considère le couplage et la cohésion pour des modules définis à l'aide de langages modulaires, on est obligé de réadapter les différentes classes. Une première adaptation a été effectuée par Macro et Buxton [Mac 87), mais elle n'est pas complètement satisfaisante en ce qui concene Je couplage, car elle repose sur une notion assez large de module pour prendre en compte des langages classiques comme Fortran ou Pascal.

Leur classification de la cohésion définit 5 types : coïncidentale, logique, temporelle, fonctionnelle et abstraite. La cohésion coïncidentale correspond à un module dont les éléments n'ont pas de liens significatifs.

La cohésion logique se réfère à des éléments liés vaguement par une fonction externe (par exemple, un module qui regroupe toutes les fonctions d'entrée/sortie). La cohésion temporelle indique des objets utilisés au même endroit et au même moment, typiquement, un module d'initialisation. La cohésion fonctionnelle traduit des éléments liés par une forte fonction logique. La cohésion abstraite correspond à un module implantant un type abstrait.

Pour nous, le but n'est pas de donner une description exacte d'un logiciel, en indiquant quel est le type exact de la cohésion de chaque module, mais d'évaluer la complexité de ce logiciel. Pour cela, les types de cohésion qui génèrent la même complexité sont mis en commun. Ainsi, nous considérons que seuls les modules ayant une cohésion abstraite ou fonctionnelle sont acceptables. et que les autres types de cohésion génèrent une plus grande complexité. Nous pénaliserons les modules qui n'ont pas une cohésion abstraite ou fonctionnelle, car un logiciel peut être consbuit

uniquement à l'aide de types abstraits [Lis 74]. Les types abstraits algébriques [Lis 75], outil de spécification, viennent renforcer cette affirmation.

L'automatisation d'un outil d'analyse de la cohésion est maintenant plus simple: il suffit de distinguer deux classes de modules. Pratiquement, là différentiation des modules ayant une cohésion fonctionnelle ou abstraite des autres modules s'effectue principalement par une analyse du type des paramètres des objets procédure des modules. Pour qu'un module soit déclaré type abstrait, il faut que les objets procédure aient, au moins, un paramètre dont le type correspond au type constituant le type de base du type abstrait. De la même manière, pour vérifier qu'un module est de type fonctionnel, on vérifie que ses objets procédure travaillent sur les mêmes types de données. Dans les cas litigieux, on regarde si les différents objets d'un module ont des dépendances communes avec d'autres objets. Il faut remarquer qu'un module ayant une cohésion fonctionnelle peut être considéré comme un type abstrait quelque peu dégénéré.

Donc, en ce qui concerne la cohésion, on classifie les modules en deux catégories: type abstrait (ou fonctionnel) et les autres. On pénalise le deuxième type en lui accordant un grand facteur de complexité.

Pour le couplage, Macro et Buxton [Mac 87) ont défmi aussi 5 types différents dont le type import-export qui indique justement le type de couplage entre des modules, où la notion de module est celle des langages modulaires. Donc, il n'y a pas besoin d'effectuer une analyse du couplage pour identifier les relations entre Jes modules pris deux à deux, car ils appartiennent tous à la même catégorie import-export.

Elanl donné que, selon cette définition, les critères de couplage ne nous sont d'aucune utilité, nous allons r~pn:uù.te la notion de couplage en nous basant sur d'autres critères. Nous allons différencier les liens de type constructeur de ceux d'utilisateur. Ces deux types vont jouer un rôle important dans le sens où le lien constructeur va nous servir à fonner des groupes de modules. Nous approfondirons cette notion de groupe de modules dans le paragraphe suivant ponant sur la structure du graphe des dépendances modulaires.

Liens de type constructeur et utilisateur

Un objet d'un module peut utiliser des objets d'autres modules. En général, ces liens sont du type utilisateur. Mais dans certains cas, ces liens traduisent une dépendance plus forte et de nature différente que celle d'une simple utilisation: ce sont des liens du type constructeur. Deux éléments sont liés par un lien de type constructeur si l'un des deux est construit sur l'autre, c'est-à-dire s'il utilise l'autre comme principal

support pour sa propre réalisation. Par exemple, un type abstrait peut être construit sur un ou plusieurs autres types abstraits. D'ailleurs, ce type de liens ne peut se produire qu'entre des modules ayant une bonne cohésion (abstraite ou fonctionnelle).

La différentiation automatique de ces types de liens n'est pas très aisée, nous allons nous baser sur des méthodes statistiques pour la réaliser.

En effet, nous avons établi, d'après examen de plusieurs cas, que lorsqu'un module est construit sur un ou plusieurs autres, il utilise une majorité des objets de ces modules et une minorité d'autres objets. Evidemment, ceci n'est vrai que pour la plupart des cas, il reste toujours des cas délicats.

Au niveau des spécifications, une règle, généralement admise, indique qu'il existe un lien de type constructeur entre deux types abstraits si l'un des types est défini à l'aide de l'autre type. On ne s'occupe pas de l'utilisation des opérations associées au type utilisé. Cette approche ne nous semble pas satisfaisante au niveau des langages de programmation car insuffisante et pas assez restrictive.

Pour établir les différents types de liens (ou de couplage), nous proposons les mesures suivantes, basées sur le nombre d'objets appartenant au module X et le nombre d'objets utilisés dans le module A, où le module A appartient à un niveau hiérarchique supérieur à celui du module X.

nombre d'objets du module X utilisés dans le module A nombre total d'objets du module X

nombre d'objets du module X utilisés dans le module A nombre total d'objets utilisés dans le module A

La première mesure donne le rapport d'objets du module X utilisés dans le module A, alors que la deuxième donne le rapport d'objets du module X utilisés dans le module A. Le nombre total d'objets utilisés dans le module A est calculé en enlevant tous les objets provenant des modules de librairie. Il faut maintenant indiquer quelles sont les valeurs limites, au-dessus desquelles on attribue le type constructeur. Pour la première mesure, on considère que la valeur se situe aux alentours de 2/3. Cette valeur peut sembler facile à atteindre pour des modules comportant peu d'objets, mais elle devient difficile pour des modules ayant un grand nombre d'objets. La valeur limite de la deuxième mesure se situe aussi aux alentours de 2/3, s'il n'y a qu'un module de base mis en cause. Mais supposons que le module A soit un type abstrait construit sur deux modules type abstrait X et Y. Alors, on ne peut pas exiger une valeur de 2/3 pour chacun de ces modules.

Les valeurs limites sont des valeurs subjectives déterminées de manière empirique. Une autre possibilité consisterait à effectuer une classification plus fme selon ct:s valeurs, c'est-à-dire à définir des classes déterminées par de petits intervalles consécutifs. Dans notre première approche, nous préférons nous contenter de deux classes séparées par une valeur limite.

Volume de données

Le volume des données échangées permet d'avoir une indication sur la complexité des échanges entre deux modules. Ce volume est calculé de manière statique: il est fonction des composants des types des objets ou de Jeurs paramètres, comme, par exemple, les paramètres d'une procédure importée.

Le volume (VD) est déterminé par les règles suivantes:

où

- soit un module A subordoIUlé à un module B, alors m

n m Clïj

Di

VDab =

~ _L...J ±

= =

=1

=0

nombre d'objets du module j=l A, nombre d'objets du module B,

s'il existe un lien entre le ième objet de A et le jème objet deB,

sinon,

nombre de composants él~me:ntaires des données échangées.

Remarque : le module A est subordonné au module B signifie que le module B importe ou utilise des objets du module A. Les composants élémentaires sont tels que définis par le langage MODULA-2.

Résumé

En résumé, pour chaque module, on indique sa cohésion (abstraite ou non), son couplage (constructeur ou utilisateur) avec les autres modules et le volume des données échangées lors de ces couplages.