Accueil > Méthode SOLIDITE – Glossaire : dépendances fortes et faibles
Sébastien Thomas
12 avril 2022

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

Dépendances fortes et faibles définition

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 »

 

Dépendance forte entre deux composants

Si A est impacté par un dysfonctionnement de B :

Composant A impacté par le dysfonctionnement de B

Si A doit attendre la fin du traitement 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 :

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) :

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é.

 

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 : o L’application affiche une erreur fatale ; o Certaines données essentielles ne sont plus affichées ; o Saisir de nouvelles informations est impossible ou l’enregistrement échoue ; o 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é.

Composants avec une faible dépendance

A n’est pas impacté par les évolutions effectuées par le projet B :

composants indépendants

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 :

echange de messages entre composants

 

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) :

API composants projet

projet complexe composants

 

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 :

Nos autres articles
Commentaires
Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Restez au courant des dernières actualités !
Le meilleur de l’actualité sur le Cloud, le DevOps, l’IT directement dans votre boîte mail.