Discussion :

[jobigoud]

Salut !


Je souhaiterais vous faire part d'un concept que je voudrais mettre en place pour un prochain logiciel. J'ignore s'il est original ou viable.

Mon objectif de conception est de bien compartimenter les pôles métiers entre eux, minimiser les interdépendances, faciliter le développement et la maintenance...
Tout ce qu'il y a de plus classique quoi :-)



L'idée de base est de décentraliser l'interface dans les .dll métiers, tout en respectant le découplage du code d'avec les interfaces.

Dans une architecture normale, la couche présentation est séparée du code métier, ce qui est une très bonne chose. Cependant si toute l'interface est groupée dans un même endroit ( un projet contenant la fenêtre principale et les contrôles ) il reste un couplage à ce niveau entre les différents sous systêmes logiques du programme.


Imaginons un logiciel composé de quatre ou cinq sous modules. Chacun de ces modules fournit des fonctionnalités particulières à l'utilisateur.
La methode classique ( je crois ) est de créer les interfaces correspondant à ces fonctionnalités et de les regrouper dans la couche présentation.
Chaque morceau de l'interface à alors accès au code métier par une dépendance descendante vers son sous module.

Lors de l'évolution du logiciel, si l'on veut par exemple ajouter un module, on va modifier la couche présentation.



Mon idée est donc de déplacer le morceau d'interface d'un sous module donné à l'intérieur du sous module en question.
Au sein du projet du sous module, on peut continuer à respecter le découplage entre la présentation et le code métier.

Si il n'y a qu'un niveau hiérarchique de modules, cette nouvelle architecture n'est pas très interessante, en effet on doit quand même modifier le module principal pour pouvoir manipuler les fonctionnalités qu'on vient d'ajouter.

Par contre si il y a plusieurs niveaux d'imbrications des modules, (la séparation logique du systême peut amener à créer une hiérarchie de dépendances) cela devient beaucoup plus interessant.
On pourrait alors ajouter un module en ne touchant qu'au module directement parent.



Pour l'instant j'en suis au stade du prototype afin de tester le concept, et j'ai implémenté la plupart de l'architecture sans rencontrer de soucis majeur. Dites moi si vous pensez que c'est viable à plus grande envergure, si ça parrait interressant ou complètement débile :-)


Avantages :
Un développeur en charge d'une sous partie du systême ne touche qu'à sa sous partie et à la manipulante. En particulier il n'y a pas d'effort d'intégration de l'interface dans une couche plus globale.

On peut mettre à jour le logiciel sans recompiler l'executable de base ( celui contenant la fenêtre mère).
La mise à jour ou l'ajout d'une dll suffisent pour modifier en profondeur ou ajouter des éléments d'interface de quelque complexité que ce soit.

Inconvénients :
Il est plus difficile de concevoir l'interface de façon globale et cohérente.
Les élements centraux de l'interface ( le menu, la barre d'outil) sont plus difficile à gérer, il faut faire remonter les informations depuis les sous-modules.

Je pense avoir trouvé quelques systemes similaires, voir allant encore plus loin en rendant les modules pluggables à chaud, mais toujours pour des usines à gaz.
Pensez vous que cette architecture soit viable pour un logiciel de taille moyenne ?

Merci de vos avis éclairés et désolé pour le roman :-D

[ego]

N'est-ce pas cela que tu cherches à faire ?

http://www.javaworld.com/javaworld/j...21-hmvc_p.html

[jobigoud]

Super !
Donc l'idée de re-décomposer les couches en une hierarchie transversale n'est pas complètement dénuée de sens

La principale différence entre l'article et ce que je propose, c'est que l'article se concentre sur la couche présentation d'une application web.
Perso, je ne me situe pas dans le cadre d'une architecture distribuée donc je peut étendre l'idée jusqu'à la couche logique, et en quelque sorte réintégrer les trois couches à chaque noeud de la hiérarchie modulaire.

Cependant le problème à résoudre est le même, et la solution est la même. Ca m'incite à creuser encore plus loin :-)

Par contre un désavantage de la technique se pose lorsqu'on a des éléments ayant trait à l'interface qui sont transversaux à tout les composants. Je pense en particulier à l'internationalisation.
Dans le modèle classique, sur une application multilingue, pour ajouter une langue, on ne modifie qu'une partie du système, les resources de langues étant probablement contenues dans la couche de l'interface graphique.

Dans ce nouveau modèle, pour ajouter une langue il faut taper dans toute la hiérarchie de modules et donc modifier l'ensemble de l'appli... ( C'est encore plus gênant dans mon architecture, où les elements de logique sont groupés avec leur interface.)

Merci pour le lien, ça me donne des idées pour la communication montante entre les modules.

[jobigoud]

J'ai trouvé !
En cherchant plus d'infos sur le pattern HMVC, je suis tombé sur le pattern PAC : Presentation-Abstraction-Control.
Et c'est exactement le systeme auquel j'ai pensé. plus d'infos ici.

En d'autres termes:
Le pattern PAC définit une structure pour les systemes interactifs, sous la forme d'une hierarchie d'agents coopérants. Chaque agent est responsable d'un aspect spécifique des fonctionnalités de l'application et comprend trois composantes : présentation, abstraction, et contrôle.

Le pattern est tiré du bouquin "Pattern-Oriented Software Architecture: A System Of Patterns" qui semble-t-il est le deuxième gros bouquin sur les patterns dans l'ombre du GoF.

Allez, je me mets en resolu 8)

[ego]

Depuis que je lis ton post, je cherchais le nom de ce pattern que j'enseignais il y a qq années et oui, c'est PAC !!!!
C'est exactement cela dont je voulais te parler.

Bon, bonne chance.......