Discussion :

[VivienD]

Bonsoir,

J'entends souvent parler d'«application monolithique» et d'«application modulaire»; je devrais plutôt dire que je lis souvent ces termes, mais là n'est pas le problème. Des nombreuses recherches que j'ai faites sur la toile — parce que ça m'énerve de ne pas comprendre ce que j'entends ou lis — je n'ai pu tirer que des définitions vagues et floues de ces notions qui me restent donc quelque peu absconses — même si j'en ai une petite idée. C'est pourquoi j'aimerais qu'on m'explique enfin ces termes et ce que ça implique concrètement.

Merci d'avance pour votre patience aide.

Bis gleesch!

PS: J'espère avoir posté ce sujet dans le forum idoine.

PPS: L'adjectif «abscons» est difficile à caser dans une discussion ... «mondaine», vous en conviendrez. Idem pour «idoine».

[nnovic]

Je ne sais pas s'il existe de définition officielle pour ces termes, mais je pense que ce sont des notions assez subjectives et je ne suis donc pas surpris que tu trouves beaucoup de réponses différentes.

D'un point de vue utilisateur, une application donne le sentiment d'être monolithique si toutes les tâches s'effectue dans le même espace de travail. Une application donne le sentiment d'être modulaire si une nouvelle fenêtre s'ouvre à chaque fois qu'on démarre une nouvelle tâche.

Mais cela ne préjuge en rien de la façon dont a été développée l'application. Un développeur appellera monolithique une application qui tient entièrement dans un seul exécutable, et la même application deviendra modulaire si elle tient sur 1 éxecutable + des librairies chargées dynamiquement.

On appelle aussi modulaire les applications qui utilisent un système de plug-in pour ajouter/enlever dynamiquement certaines fonctionnalités.

Enfin voilà quoi, c'est assez flou, je crois!

[el_slapper]

Effectivement, il y a le point de vue de l'utilisateur, et le point de vue de l'architecte/développeur. Il PEUT y avoir corrélation entre les deux, mais je n'en suis absolument pas sur.

D'un point de vue développeur, une appli modulaire, c'est une appli dont l'architecture est en petits morceaux indépendants - qu'on peut rajouter ou retirer facilement sans rien casser. Une appli monolithique, c'est une appli ou tout retrait ou ajout change absolument tout. D'un point de vue développeur, une appli se doit d'être modulaire.

Du point de vue de l'utilisateur, c'est plus complexe. Une appli ou on ne se rend même pas compte qu'on a changé de sous-appli peut être très rassurante et efficace.

[VivienD]

Je vois un peu mieux. En revanche, une question subsiste: est-ce qu'une application modulaire, du point de vue des développeurs, implique automatiquement la gestion de greffons ou une pléthore de bibliothèques pour un exécutable ... aussi «minimaliste» que possible?

[el_slapper]

Je vois un peu mieux. En revanche, une question subsiste: est-ce qu'une application modulaire, du point de vue des développeurs, implique automatiquement la gestion de greffons ou une pléthore de bibliothèques pour un exécutable ... aussi «minimaliste» que possible?

EDIT : C'est le principe pour les sources. Un seul source énorme qui passe même l'aspirateur, c'est le cauchemar. Il FAUT découper son source en petits morceaux.

Par contre, pour l'executable, c'est une question de choix architectural. On peut essayer de tout compiler sous un executable unique, ou au contraire avoir une galaxie d'executables. Je suis partisan de la deuxième solution, et c'est la plus fréquente, mais la première a aussi ses qualités.

[dba01]

On trouve aussi l'organisation de gros systèmes :

J'ai travaillé, il y a quelques temps, sur une appli faisant partie d'un ensemble comptable. Elle n'était composée que d'un ensemble de tâches lancées par un ordonnanceur indépendant ($Universe). Ce dernier pilotant aussi quelques centaines d'autres applications et diverses copies de données d'une machine à l'autre.
On a bien alors un lot de modules complètement indépendants, en nombre variable dans le temps, regroupés sous un nom d'application mais complètement autonomes si ce n'est qu'ils exploitent des données communes.
Pour éviter les parasites, l'ordonnanceur de tâches doit alors tenir compte de paramètres de lancement : horaire, ou bien exécution réussie d'une autre tâche (traitement après filtrage réussi), ou inversement non exécution (pas d'accès utilisateur pendant les chargement de données), ou lancement manuel à la demande (stats, purges).

L'inconvénient ici, c'est que toutes les vérifs doivent être paramétrées dans le module. On ne peut pas compter sur une mémoire quelconque pour servir de référence à une exécution. Hors la base de données accessible partout, aucun programme ne peut revenir sur le précédent. Par exemple, si la base des dates de traitement n'est pas conforme aux dates des données, le module de traitement de ces données ne peut pas corriger. Il doit être interrompu pour relancer le module de gestion des dates, puis relancé à zéro quand l'ordonnanceur (ou l'opérateur) aura reçu le feu vert attendu.
Chaque module gère ici un sujet déterminé en totale autonomie, mais pour une même BDD.

Voir ensuite l'éventualité de cette organisation dans une petite application ne traitant qu'un sujet limité.

[VivienD]

Alors une application modulaire peut aussi être un exécutable qui gère tout un ensemble d'exécutables dont la portée de chacun est plus nettement restreinte et ciblée et qui sont indépendants les uns des autres... Ça me donne envie de m'attarder sur ce dernier concept (cf. mon avatar pour voir la belle tête de sadique que je suis en train de faire), mais la complexité de la programmation d'une telle application me semble beaucoup plus relevée qu'en ce qui concerne de «simples» monolithes applicatifs. J'imagine ce que la gestion temporelle des threads, des processus et des sémaphores doit être pour une telle bête; je wanda très mal sur ça, mon frère!

[pseudocode]

D'un point de vue développeur, une appli modulaire, c'est une appli dont l'architecture est en petits morceaux indépendants - qu'on peut rajouter ou retirer facilement sans rien casser.

Il y a généralement une dépendance entre les composants, du genre "fournisseur -> consommateur" d'un service ou d'une fonction.

Pour préciser ta définition, je dirais que dans une application modulaire il n'y a pas d'inter-dépendance fonctionnelle entre 2 composants. Visuellement, on pourrait dire que la chaine fonctionnelle traverse les interfaces sans faire de boucles.

La modularité est souvent atteinte en imposant la spécification des interfaces, afin d'éviter de "faire des noeuds" dans l'architecture. On met aussi généralement en oeuvre des bonnes pratiques comme le couplage faible/cohésion forte.

[el_slapper]

Merci pseudocode, je m'aperçois que je n'avais pas été parfaitement clair(pour rester poli).

[VivienD]

[...]

Pour préciser ta définition, je dirais que dans une application modulaire il n'y a pas d'inter-dépendance fonctionnelle entre 2 composants. Visuellement, on pourrait dire que la chaine fonctionnelle traverse les interfaces sans faire de boucles.

[...]

Quand tu dis qu'il n'y a aucune interdépendance entre modules et application modulaire, je ne suis pas tout à fait d'accord. En effet, si j'ai bien compris le concept, les greffons, qui représentent une partie des briques d'une application modulaire, sont normés pour correspondre à une interface application-greffon qui dépend intrinsèquement de l'application concernée. Quand bien même l'interdépendance est infime, on ne peut, par exemple, pas utiliser un greffon de Firefox avec Internet Explorer, Safari ou Google Chrome.

[pseudocode]

Quand tu dis qu'il n'y a aucune interdépendance entre modules et application modulaire, je ne suis pas tout à fait d'accord. En effet, si j'ai bien compris le concept, les greffons, qui représentent une partie des briques d'une application modulaire, sont normés pour correspondre à une interface application-greffon qui dépend intrinsèquement de l'application concernée. Quand bien même l'interdépendance est infime, on ne peut, par exemple, pas utiliser un greffon de Firefox avec Internet Explorer, Safari ou Google Chrome.

Dans cet exemple, il y a bien un "sens" dans la dépendance fonctionnelle. Ici, Firefox a besoin du greffon pour apporter la fonctionnalité souhaitée (par exemple l'affichage d'un contenu flash). Firefox consomme un service et le greffon produit un service.

Un cas d'interdépendance serait par exemple un programme avec une IHM et un traitement. L'IHM déclenche le début du traitement, et le traitement à besoin à un moment d'informations provenant de l'utilisateur pour continuer (genre une application web). L'IHM et le traitement se retrouvent dépendant l'un de l'autre. Le résultat c'est un programme qui n'est pas modulaire.

Je ne sais pas si je suis bien clair.

[VivienD]

Hum... Pourtant, un greffon peut devoir utiliser des données entrées par l'utilisateur ou les résultats du traitement de ces données pour fonctionner. Est-ce que ce genre de greffon casse la modularité de l'application à cause de cette interdépendance?

PS: Est-ce que IHM veut dire Interface Homme-Machine?

[pseudocode]

Hum... Pourtant, un greffon peut devoir utiliser des données entrées par l'utilisateur ou les résultats du traitement de ces données pour fonctionner. Est-ce que ce genre de greffon casse la modularité de l'application à cause de cette interdépendance?

Dans ce cas, ca casse la modularité "fonctionnelle": on ne peut pas dire comment va se comporter le greffon sans savoir comment fonctionne Firefox, et réciproquement.

Évidemment, on a toujours une modularité "technique" car le code de chaque composant est distinct et l'interface est bien définie.

PS: Est-ce que IHM veut dire Interface Homme-Machine?

oui.

[VivienD]

Alors, la modularité fonctionnelle implique que les modules puissent travailler en parfaite indépendance vis-à-vis des autres modules et de l'application, pas la modularité technique.

[_skip]

Dans ce cas, ca casse la modularité "fonctionnelle": on ne peut pas dire comment va se comporter le greffon sans savoir comment fonctionne Firefox, et réciproquement.

Évidemment, on a toujours une modularité "technique" car le code de chaque composant est distinct et l'interface est bien définie.

oui.

Tiens je ne connaissais pas cette différentiation.

On peut alors se poser la question suivante : Existe-t-il à ce moment d'autres solutions pour une modularité "fonctionnelle" que d'avoir recours au multiprocessing? Soit finir avec des exécutables séparés qui s'appellent par ligne de commande?

[souviron34]

On peut alors se poser la question suivante : Existe-t-il à ce moment d'autres solutions pour une modularité "fonctionnelle" que d'avoir recours au multiprocessing? Soit finir avec des exécutables séparés qui s'appellent par ligne de commande?

ça pourrait être aussi des serveurs qui se parlebt par protocole, des fonctions enregsitrées style callbacks, ...

C'est un très vaste sujet...

[pseudocode]

Alors, la modularité fonctionnelle implique que les modules puissent travailler en parfaite indépendance vis-à-vis des autres modules et de l'application, pas la modularité technique.

la modularité fonctionnelle d'un composant implique que ses fonctions (publiques) soient indépendantes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
C1 {
  f1(input) {
    return C2.g(input);
  }
  f2(input) {
      return 0;
  }
}

C2 {
  g(input) {
    return 1;
  }
}

S'il y a une interdépendance, on doit considérer les 2 composants comme un seul "gros" module.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
C1 {
  f1(input) {
    return C2.g(input);
  }
  f2(input) {
    return 0;
  }
}

C2 {
  g(input) {
    return 1+C1.f2(input);
  }
}

On peut alors se poser la question suivante : Existe-t-il à ce moment d'autres solutions pour une modularité "fonctionnelle" que d'avoir recours au multiprocessing? Soit finir avec des exécutables séparés qui s'appellent par ligne de commande?

Bah heu... oui. Il suffit d'avoir une claire différenciation entre les fonctions qui "produisent" des données, et celles qui en "consomment". Par exemple une archi web 3-tiers, est une architecture modulaire...

[VivienD]

la modularité fonctionnelle d'un composant implique que ses fonctions (publiques) soient indépendantes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
C1 {
  f1(input) {
    return C2.g(input);
  }
  f2(input) {
      return 0;
  }
}

C2 {
  g(input) {
    return 1;
  }
}

[...]

Euh... ton exemple me laisse perplexe: est-ce que la fonction C1.f1(input) ne dépend-elle pas de la fonction C2.g(input)? Si oui, est-ce que ça casse alors la modularité fonctionnelle, à moins que l'on considère C1 et C2 comme faisant partie d'un même module?

[pseudocode]

Euh... ton exemple me laisse perplexe: est-ce que la fonction C1.f1(input) ne dépend-elle pas de la fonction C2.g(input)? Si oui, est-ce que ça casse alors la modularité fonctionnelle, à moins que l'on considère C1 et C2 comme faisant partie d'un même module?

Heu... S'il n'y avait pas de dépendances, on n'aurait aucun problème. On ne se poserait meme pas la question de la modularité. Faire une architecture modulaire, ca implique que les modules se parlent entre-eux.

Peut-être que c'est plus compréhensible avec ce genre d'exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Firefox {
  display_flash(bytecode) {
    return FlashPlayer.render(bytecode, window);
  }
}

FlashPlayer {
  render(bytecode,window) {
    // do rendering directly in window
    return OK;
  }
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Firefox {
  display_flash(bytecode) {
    return FlashPlayer.render(bytecode, window);
  }
  display_image(window, bitmap) {
    // display bitmap here
    return OK;
  }
}

FlashPlayer {
  render(bytecode,window) {
    loop {
      // compute one image here
      Firefox.display_image(window, image);
    } 
    return OK;
  }
}

[VivienD]

OK. Alors l'architecture applicative pour la modularité fonctionnelle ressemble un peu à une architecture serveur-client, si j'ai bien compris.