Méthode SOLIDITE – Glossaire : dépendances fortes et faibles

Dans le cadre de notre série d’articles autour de la maitrise d’un projet avec la méthode SOLIDITE, nous vous proposons quelques définitions pour mieux appréhender les dépendances dans un projet.
Les différentes topologies de dépendances / couplages
Pressman définit dans son précis d’architecture ((Pressman R. S., Software Engineering: A Practitioner’s Approach Chapitre 10) 7 niveaux de dépendances ou couplages :
- Sans couplage: les composants n’échangent pas d’information.
- Par données: les composants échangent de l’information par des méthodes utilisant des arguments (paramètres) de type simple (nombre, chaîne de caractères, tableau).
- Par paquet: les composants échangent de l’information par des méthodes utilisant des arguments de type composé (structure, classe).
- Par contrôle: les composants se passent ou modifient leur contrôle par changement d’un drapeau (verrou).
- Externe: les composants échangent de l’information par un moyen de communication externe (fichier, pipeline, lien de communication).
- Commun (global): les composants échangent de l’information via un ensemble de données (variables) commun.
- Par contenu (interne): les composants échangent de l’information en lisant et écrivant directement dans leurs espaces de données (variables) respectifs.
Cependant, pour simplifier, il est préférable de raisonner avec ces 2 typologies de dépendances seulement :
- Les dépendances fortes
- Les dépendances faibles
Les dépendances fortes
Un composant informatique A est dit fortement dépendant d’un composant B si l’absence ou le dysfonctionnement de B entraine un dysfonctionnement pour A.
=> “Plus les impacts sont importants et plus la dépendance est forte”
Si A est impacté par un dysfonctionnement de B :
Si A doit attendre la fin du traitement de B :
Si des évolutions sur B entrainent des recherches d’impact et des évolutions contraintes sur A :
accède directement à une ressource de B (ex. base de données, fichiers sur un disque) :
Exemples :
Une application de prise de commande est fortement dépendante du serveur de base de données. Lorsque le serveur de base de données est injoignable :
- L’application affiche une erreur fatale ;
- Certaines données essentielles ne sont plus affichées ;
- Saisir de nouvelles informations est impossible ou l’enregistrement échoue ;
- Un rapport de gestion n’affiche aucune donnée ou des données partielles.
Les dépendances faibles
Un composant informatique A est faiblement dépendant d’un composant B si, malgré l’absence de B, A ne connait pas de dysfonctionnement majeur.
A noter : cela peut être un mode dégradé.
A n’est pas impacté par les évolutions effectuées par le projet B :
Si A et B possèdent un mécanisme d’échange de messages / file d’attente : B peut traiter les messages à son rythme et A peut afficher un statut du traitement à l’utilisateur :
Si A n’accède qu’à des interfaces ou des abstractions mises à disposition par le projet de B (une API, une vue plutôt qu’une requête complexe sur la table de B) :
Exemples :
- Un rapport ou une application avec des données en cache : les données sont mises à jour lorsque le serveur est de nouveau en ligne.
- Une application hors ligne qui permet des modifications et attend d’être connectée à un serveur pour envoyer les changements faits hors connexion. (ex: Outlook, oneDrive…).
- Des applications ou services qui créent des messages sur une file d’attente pour le service facturation. Le serveur gérant ces messages de facturation peut lui aussi être déconnecté et ne les traiter que plus tard.
Note : Dans le dernier exemple, l’application est en dépendance faible avec le service de facturation. Néanmoins, l’application est en dépendance forte avec le service de file d’attente qui gère la réception des messages. Il sera nécessaire de s’assurer que ce service intermédiaire possède un haut niveau de disponibilité ou de mettre d’autres systèmes en place pour palier son dysfonctionnement.
Lire les articles sur la méthode SOLIDITE :