Comme le montre l’exemple 8, les développeurs doivent gérer les dépendances qui résultent de leur décomposition d’un problème et de sa solution en un certain nombre de modules. Nous disons qu’un module d’un système dépend d’un autre s’il est possible qu’une modification d’un module nécessite une modification d’un autre. Par exemple, si une entreprise modifie ses méthodes de production, cela peut entraîner un changement conséquent dans la façon dont elle calcule les paiements nécessaires pour les biens qu’elle produit.
Un développeur doit non seulement traiter la nature de chaque dépendance mais aussi le nombre de dépendances. En génie logiciel, le terme » couplage » est utilisé pour désigner le degré d’interdépendance entre les différentes parties d’un système. Il est facile de constater que certains systèmes peuvent avoir des chaînes de modules interdépendants où, par exemple, le module A dépend du module B, qui dépend du module C, et ainsi de suite. Dans certains cas, ces chaînes peuvent se rejoindre et créer une dépendance circulaire, qui est une forme particulière de couplage fort (ou élevé).
Les développeurs essaient de construire des systèmes faiblement couplés car ils sont plus faciles à comprendre et à maintenir. Ainsi, un bon système logiciel présente un couplage faible, ce qui signifie que les modifications apportées à une partie sont moins susceptibles de se propager dans le reste du système. Un autre avantage du faible couplage est que les composants sont faciles à remplacer et, potentiellement, à réutiliser.
Quel que soit le niveau de couplage dans un système logiciel, il est important de savoir quels modules sont couplés. S’il n’y avait pas d’enregistrements du couplage entre les modules, un développeur devrait passer du temps à travailler à travers les modules pour déterminer si chacun d’entre eux est affecté ou non par un changement. Le résultat serait un effort important consacré à la vérification, même si aucune modification n’était nécessaire. L’exemple 9 illustre le danger d’avoir plus d’un module faisant usage de données communes ou partagées.
Exemple 9
La manipulation des dates a toujours été un problème pour les développeurs de logiciels. Pour les applications d’un certain âge, le format de stockage le plus applicable pour représenter une année était un nombre compris entre 0 et 99. C’était logique car 1966 était stocké comme 66, 1989 comme 89, et ainsi de suite, donc moins d’espace était nécessaire pour stocker seulement deux chiffres. En outre, si les dates étaient stockées comme des nombres, les tâches qui impliquaient un tri par ordre de date étaient simples – le 22 janvier 1989 stocké comme 890122, est après le 22 décembre 1966 stocké comme 661222.
Malheureusement, un certain nombre de ces applications étaient encore utilisées à l’approche de l’an 2000, de sorte que chaque module de chaque application qui utilisait la forme courte de l’année devait être examiné.
Un aspect majeur du problème de l’exemple 9 était que différents développeurs avaient différentes façons de lire et de manipuler les valeurs stockées dans les variables qui utilisaient le format de date à six chiffres. Cela a augmenté l’effort nécessaire pour résoudre le soi-disant bogue du millénaire. Si les développeurs avaient eu une façon cohérente de manipuler les dates qui ne dépendait pas du format de stockage, le bogue du millénaire n’aurait pas été un sujet de préoccupation.
La cohésion est une façon de décrire à quel point les activités d’un même module sont liées les unes aux autres. La cohésion est un concept général – par exemple, un département dans une organisation peut avoir un ensemble cohésif de responsabilités (les comptes, disons), ou pas (services divers). Dans les systèmes logiciels, un module hautement cohésif exécute une tâche ou atteint un objectif unique – « faire une chose et la faire bien » est une devise utile à appliquer. Un module doit mettre en œuvre une seule tâche logique ou une seule entité logique.
Le faible couplage et la forte cohésion sont des objectifs concurrents. Si chaque module ne fait qu’une seule chose à un faible niveau d’abstraction, nous pourrions avoir besoin d’un édifice complexe de modules fortement couplés pour réaliser une activité à des niveaux d’abstraction plus élevés. Un développeur doit essayer d’atteindre le meilleur équilibre entre les niveaux de couplage et de cohésion pour un système logiciel. Par exemple, les hôtels génèrent des revenus en louant leurs chambres aux clients. Le concept de chambre est susceptible d’être représenté quelque part dans le système logiciel de réservation d’un hôtel. Il peut être pratique d’utiliser un module ou une classe représentant le concept de chambre pour collecter et stocker des données sur les revenus générés par la location de chambres. Cependant, une meilleure solution est d’avoir un module de facturation ou de paiement distinct, car il est plus cohérent, surtout lorsqu’un hôtel génère des revenus d’autres façons, par exemple, en servant des repas à des personnes qui ne sont pas des clients résidents.
Activité 5 Diviser et conquérir
- a.Pourquoi envisager de diviser un grand projet en plus petits morceaux ?
- b.Comment la complexité d’un système logiciel affecte-t-elle la tâche de maintenance ?
- c.Qu’est-ce qu’un module ?
- d.Pourquoi est-il utile d’avoir un faible couplage dans un système logiciel ?
- e.Donnez des exemples des types d’informations qui seraient précieuses lors de l’examen d’une modification d’un module donné.
- f.Quelles sont les dépendances contextuelles d’un module ? Comment sont-elles liées à l’interface d’un module ?
- g.Quels sont les avantages de l’utilisation de modules avec des interfaces définies ?
- h.Pourquoi est-il utile d’avoir une grande cohésion dans les modules d’un système logiciel ?
- i.Quelles sont les caractéristiques qu’un module doit présenter qui contribueront à garantir qu’il est facile et peu coûteux à développer et à maintenir, et que les erreurs sont réduites au minimum ?
- j.Pourquoi est-il important d’atteindre un équilibre entre le couplage et la cohésion ?
Réponse
- a.Il y a une limite à ce qu’une personne peut comprendre à un moment donné. Il y a donc une limite à la taille d’un système logiciel qu’une seule personne peut traiter. En divisant un grand projet en petits morceaux, il est possible d’identifier un certain nombre de tâches plus faciles à gérer pour les personnes impliquées.
- b.Il est essentiel de pouvoir apporter un changement à un système logiciel sans avoir à tout connaître de ce système. Chaque changement devient difficile lorsque le flux de contrôle et les dépendances au sein des programmes sont complexes. Plus le nombre et la nature des dépendances sont importants, plus il est difficile de maintenir un système logiciel.
- c.Un module est toute partie identifiable d’un système logiciel qui est considérée séparément. Par exemple, les modules peuvent être des sous-routines (dans un langage procédural équivalent aux méthodes), des classes (dans un langage orienté objet), des fonctions de bibliothèque ou d’autres constructions qui peuvent être traitées indépendamment.
- d.Avec un couplage faible, il y a peu de dépendances entre les modules. Par conséquent, les modifications apportées à une partie (un ou plusieurs modules) d’un système logiciel sont moins susceptibles de se propager dans l’ensemble du système. (Un enregistrement clair des dépendances entre les modules vous aide à prédire l’impact d’un changement proposé sur un système logiciel.)
- e.Deux types d’informations contribuent à l’analyse d’un changement proposé :
- Quels modules sont clients du module en question ? Cette information indique dans quelle mesure un changement peut se propager dans le système logiciel.
- Quelles hypothèses ont été faites dans les modules clients du module en question ? Une compréhension des services attendus d’un module aidera à évaluer les risques associés à un changement particulier.
- f.Les dépendances de contexte pour un module sont les services d’autres modules dont le module a besoin pour fonctionner correctement. Vous pouvez exprimer les dépendances contextuelles d’un module en termes d’autres interfaces. En effet, vous pouvez exprimer les responsabilités d’un module en termes d’interface et de dépendances de contexte. Si le contexte fournit les services dont le module a besoin et que les clients remplissent toutes les conditions spécifiées dans l’interface, le module peut garantir la fourniture des services décrits dans son interface.
- g.Les avantages sont les suivants :
- Les développeurs n’auront besoin de connaître que l’interface du module (sa syntaxe et ce qu’elle exige et réalise – sa sémantique), et non la manière dont elle fournit ces services. Par conséquent, les développeurs peuvent être plus productifs.
- Les développeurs peuvent comprendre les aspects du système logiciel de manière plus approfondie, de sorte que moins de bogues seront introduits.
- Il devrait être plus facile de trouver des bogues, car les modules non pertinents sont évités.
- La possibilité de réutilisation du module est augmentée une fois que l’on sait ce que ce module fournit et exige.
- h.Avec une cohésion élevée, un module effectue un ensemble sensible d’opérations ou d’activités. Idéalement, une cohésion élevée implique une seule abstraction majeure par module. L’interface s’abstrait de ce qu’un développeur doit savoir pour utiliser un module. Il est ainsi plus facile pour les développeurs de comprendre l’objectif du module et la manière de l’utiliser. En outre, une cohésion élevée tend à rendre un module plus réutilisable dans d’autres applications, car il fournit un ensemble d’opérations qui s’assoient naturellement ensemble.
- i.Un module devrait avoir un couplage faible et une cohésion élevée, représenter une bonne abstraction, et avoir une interface bien définie qui est une abstraction encapsulée d’un concept bien compris.
- j.Lors de la construction d’un système, vous pouvez avoir le choix entre un ensemble plus petit de modules faiblement couplés et moins cohésifs, ou un ensemble plus grand de modules étroitement couplés et plus cohésifs. Dans le premier cas, chaque module peut être difficile à comprendre, tandis que dans le second cas, les relations entre eux peuvent être trop complexes. Vous devez trouver un équilibre approprié.
.