Discussion :

[rimas2009]

Bonjour tout le monde,
y a une notion qui m'échappe sur la différence entre l'architecture 3 tiers et 4 tiers :

l'architecture 3 tiers :
- une couche présentation (IHM)
- une couche métiers
- une couche accès aux données

dans l'architecture 4 tiers, une couche applicative est introduit entre la couche présentation et métiers;
pouvez-vous SVP m'expliquer a quoi sa sert ?? avec un exemple concret ??
Merci

[souviron34]

dans l'architecture 4 tiers, une couche applicative est introduit entre la couche présentation et métiers;
pouvez-vous SVP m'expliquer a quoi sa sert ?? avec un exemple concret ??
Merci

Tout simplement à pouvoir changer d'outil et/ou d'IHM sans pour autant changer la majeure partie de l'application...

Exemple :

fiare une appli qui peut tourner simultanément en interactif et en batch... mais avec les mêmes fonctionalités...




Exemple concret :

faire un programme de traitement d'images accessible autant par une IHM que par un langage de commande.


Chaque fonctionalité d'IHM doit être accessible par commande


la couche IHM sera donc spécifique. La couche"fonctionalité d'IHM" sera commune.


Par exemple, tu veux lancer une animation MPEG..

Dans ton IHM interactive, tu auras un champ nom du fichier , et un bouton Visualiser.

Dans ton langage de commande tu auras un paramètre nom du fichier et une commande Visualiser.

Mais chacune de ces 2 actions aboutira au même résultat.

Donc, pour minimiser bugs et nombre de lignes de code à développer et maintenir, on crééra un module intermédiaire, qui prendra en entrée un nom de fichier et lancera l'affichage.



J'ai volontairement choisi un exemple simple. Mais par exemple avec ce type de modèle tu peux créer une interface Java, une en C++, une en VB, une en X11, une en langage de commande, et avoir le même code fonctionnel derrière...

Le passage d'un outil d'IHM à l'autre ne nécessitera alors simplement que strictement la "recopie" des écrans et de leurs comportement...

[IDontLikeYou]

Bonjour tout le monde,
y a une notion qui m'échappe sur la différence entre l'architecture 3 tiers et 4 tiers :

l'architecture 3 tiers :
- une couche présentation (IHM)
- une couche métiers
- une couche accès aux données

dans l'architecture 4 tiers, une couche applicative est introduit entre la couche présentation et métiers;
pouvez-vous SVP m'expliquer a quoi sa sert ?? avec un exemple concret ??
Merci

Attention, tu confonds les couches et les tiers...

[Ecosmose]

Attention, tu confonds les couches et les tiers...

Oui en effet... je pense que ça répond bien à sa question...

Merci souviron, par simple curiosité :

Je ne vois pas directement comment tu pourrais bénéficier de la définition des interfaces applicatives au sein du projet IHM.

comment 'câblerais' tu une telle modularité pour ce changement d'IHM Java, VB, C++ , .NET ?
insertion d'une bibliothèque dans un projet de prog. et implémentation du framework ou appele d'interface ?

[souviron34]

Merci souviron, par simple curiosité :

Je ne vois pas directement comment tu pourrais bénéficier de la définition des interfaces applicatives au sein du projet IHM.

comment 'câblerais' tu une telle modularité pour ce changement d'IHM Java, VB, C++ , .NET ?
insertion d'une bibliothèque dans un projet de prog. et implémentation du framework ou appele d'interface ?

Assez simple...


Admettons par exemple que l'on aie comme fonctionalité l'affichage d'un fond , et l'affichage de polygones ou de lignes brisées, et l'affichage de textes.

De manière conceptuelle pure, ceci se traduit simplement par quemques opérations simples :

• fill area
• draw line
• draw text

Une analyse simple permet d'identifier ce dont on a besoin :

• Pour un texte, il faudra une coordonnée (de départ ou de centre) une taille, éventuellement une couleur , et éventuellement un angle.
• Pour remplir une zone, il faudra une coordonnée de départ, une largeur et hauteur, une couleur, et éventuellement un style de remplissage
• Pour tracer une ligne, il faudra un ensemble de coordonnées, un style de trait, une couleur, une épaisseur

Tout ceci est strictement indépendant de l'outil graphique avec lequel on va le faire, et cela décrit cependant une fonctionalté d'IHM.

On peut donc tout à fait concevoir un outil (une biblothèque) définissant une structure de données graphqiues génériques, avec une API du style :

(je donne un exemple en C) :

Code C :

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

1
2
3
Draw_Text ( struct *IndptIHM, char *Texte, int x , int y, int Taille, int Color, double Angle )
Draw_Line ( struct *IndPtIHM, int *x, int *y, int NPts, int Thickness, int Color, int Style )
Fill_Area ( struct *IndptIHM,  int x, int y, int width, int height, int Color, int Style)

La structure IndtPtIHM peut contenir comme parent un pointeur (de type "void" car inconnu et surtout qu'on ne veut pas connaître) vers une structure sépcifique à l'outil considéré, qui permettra de réellement effectuer les opérations.

Par exemple, toujours en C :

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
typedef struct {
 
   void *Parent ;
 
   int MaCouleur ;
   int MonEpaisseur 
   int MesX[20] ;
   int MesY[20] ;
   .....                 /* Tous mes paramètres repérés à l'analyse 
                             comme étant génériques */
} IndPtStruct ;

Une bibliothèque implémentant cette API sera à écrire pour chacun des langages considérés (dans ton exemple Java ou .Net)

Si par exemple j'utilise X11, j'aurais, en C :

Code C :

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

1
2
3
4
5
6
7
8
typedef struct {
 
    IndPtStruct  MaStruct ;  /* La structure indépendante de l'outil */
 
    Display  dpy ;   /* Tous paramètres dépendants de l'outil */
    GC gc ;
   ...
} IMHStruct_X11 ;

La fonctionalité sera codée (et éventuellement compilée), elle, de manière indépendante comme simpement l'appel correspondant à l'API donnée ci-dessus au début.

Et donc il suffira à l'édition de lien de lier avec la biblothèque du langage considéré et on aura instantanément toute la fonctionalité avec un autre outil..

Alors quand la fonctionalité est simple, il n'y a pas de problèmes à ne pas faire ça.

Mais quand la fonctionalité d'IHM est complexe et est le coeur du métier, il est de très loin préférable de faire ce genre d'architecture, le passage d'un outil à l'autre se limitant à refaire les fenêtres et réécrire ces petites bibliothèques : elles sont petites, puisqu'en gros il suffit d'écrire les fonctionalités élémentaires de base (tracer un trait, une ligne, un texte, une image, un fond..).

De même, la traduction des fenêtres est rapide, car si le code fonctionnel est indépendant, la seule chose qui reste à faire est refabriquer une fenêtre visuellement similaire, reproduire les appels, et reproduire les interdictions/libérations d'accès aux boutons et/ou changements de police ou autres...





Dans un logiciel que j'ai fabriqué destiné à des opérations critiques et dont la fonctionalité visuelle était essentielle et complexe, par exemple, sur 700 000 lignes de code, un peu moins de 60 000 (9%) étaient liées à la fabrication des fenêtres et ce code d'implémentation d'API. Alors que le projet a duré 9 ans, et qu'il était fait pour marcher avec X11 et Motif, avec cette structure, le passage sur Windows et le passage en outil automatique à base de commandes n'a pris que 3 mois pour le passage à Windows et 1 mois 1/2 pour la fabrication de l'outil automatique (en sortie GIF).


Comme je l'avais dit dans le post initial, cela dépend du projet, des possibilités d'évolution, et de la lourdeur / complexité / criticalité de la partie fonctionnelle de l'IHM.


Si on prend l'analogie de la fouille d'une base de données, il est évident que si tout ce que l'on demande à l'utilisateur est d'entrer un nom et de lui sortir ce que contient la base dans une liste, il n'y a pas besoin de faire ceci.

Mais si la fonctionalité visuelle est complexe, difficile à tester, et comprend beaucoup de choses, cette approche est la plus pratique et simple.



PS: le projet pour lequel j'ai appliqué ceci était un SIG de données météo, avec affichage en boucle évolutive des données (diverses) arrivant dans des BDD diverses en temps réel, avec des durées de vie diverses.. et devant tourner en temps réel pendant toute la journée, avec suivant les moments focalisation sur tel ou tel aspect, et donc modification quasi-permanente des paramètres de visulaisation (endroit zoomé, facteur du zoom, durée affichée, couleurs, ...).. La fonctionalité de cette boucle d'affichage était donc tellement complexe que c'était le coeur du métier, tout en étant de l'IHM. Une structure indépendante de l'outil d'affichage a donc permis de debugger uniquement la partie fonctionnelle, et une fois ceci fait de permettre plusieurs versions simultanées du même outil fonctionnant sous Windows, sous Linux, en batch, avec très peu d'effort.. et sans re-débugger la fonctionalité du coeur... qui était de très loin (4/5) le plus gros du code...

En gros, faire une fois le boulot, et savoir que quelque soit l'évolution on n'y touchera plus. Et que si un client demande une autre version, ou qu'une autre plateforme apparaît, on ne doit pas tout refaire mais juste une petite partie (c.a.d. à un coût et un délai bien moindre)

[souviron34]

j'ajouterais que l'avènement d'outils/langages/IDE comme VB, VC++, Java ou NetBeans, et mêlant IHM et opérations "de programmation" hors IHM , et étant de plus la base de l'enseignement OO et de la pratique des programmeurs n'ayant pas connu autre chose implique une discipline très stricte pour se rendre compte de l'avantage de ces structures..

On voit tous les jours ici sur ce forum "conception" des questions et des usines à gaz (soit lourdes soit mal conçues car justement liant ce qui est fonctionnel à ce qui est affichage), prouvant que le concept de la séparation est devenu totalement secondaire, alors que c'est une partie vitale pour développer efficacement à moindres frais un logiciel évolutif...


Le fait du basculement de beaucoup d'applications vers des services Web explique en partie, mais ne suffit pas..

Car même avec des applis Web, les différents standards ou leur évolution, les différents langages ou autres, ne changent strictemnt rien d'un point de vue conceptuel, même pour une bête petite application d'interaction avec une BDD :

La fonctionalité de ce forum, par exemple, peut être simplement découpée par des fonctionalités indépendantes du fait que c'est du Web, et aussi du type de BDD étant en dessous.

Mais même encore plus simple :

une page permettant d'interroger une BDD (et les exemples ici sont nombreux de projets gérant par exemple une classe, une biblothèque, ou autre), et donc demandant par exemple un nom et un horaire, et allant fouiller une base.

Quel que soit le langage / paradigme d'affichage utilisé (lourd ou léger, .net, c#, Java, ou autre) , en entrée on a par exemple un nom et une date, en sortie une liste.

Quelle que soit la base (oracle, flat file, ou autre) c'est pareil.

Et ceci ne changera pas si d'un seul coup le propriétaire du site décide de passer de Oracle à un flat file ou à Mysql ou autre...

De même , ceci ne changera pas si pour fabriquer la page on n'utilise plus .net mais le langage qui sortira dans 3 ans....

N'importe quelle page de ce type devrait donc être conçue avec un tampon indépendant, faisant le boulot qu'on lui demande, sans plus.

[Ecosmose]

Une bibliothèque implémentant cette API sera à écrire pour chacun des langages considérés (dans ton exemple Java ou .Net)

Ok, j'ai ma réponse dans le passage cité ci-dessus. Je parlais d'une réutilisation directe des API d'un language dans un autre... Je pensais que vous aviez trouvé quelques choses que je ne connaissais pas (j'ai relu votre réponse, et vous apportiez déjà les conditions d'inter opérabilité à l'aide d'API et d'interfaces dans ce même language)

merci pour vos réponses, il apporte des perspectives utiles à l'insertion d'une couche (et pas tiers ^^) entre IHM et métier, que l'on nomme très souvent controlleur. Une pierre angulaire qui favorise les isolations et indépendance par couches et la capacité d'une application à être modulable.

Merci pour ces explications et détails, c'est appréciable.

[souviron34]

De rien

Une pierre angulaire qui favorise les isolations et indépendance par couches et la capacité d'une application à être modulable.

Absolument..

C'est ce qui manque beaucoup (oserai-je dire principalement) dans les devs usuels, et en particulier comme je le citais depuis l'avènement des IDE et langages "all included"..

Et après on s'étonne des coûts de développements, du nombre de bugs et erreurs (n'ayant guère changé au cours des 25 dernières années), etc etc..


Disons que les "modèles" MVC et autres , en formalisant la couche C comme un "pattern", est à mon avis défaillante dans la mesure (et il suffit de voir sur ce forum) où on ne précise pas l'effort de conception impliqué pour séparer l'IHM du reste...

A cause des langages/outils tout inclus, des terminlogies "pattern", et de l'avalanche de termes techniques et de confusion métholodgies / outils / réflexion, ceci devient abstrait et "embedded", alors que c'est un point essentiel, qui apparaissait de manière beaucoup plus éclatante avec les modèles style Waterfall et cycle en V, lors de la phase de "conception préliminaire"...



Un excellent exemple de mauvaise séparation fût (je ne sais pas si ça a changé) les bibliothèques sockets sous Windows :

Alors que les normes ISO de développement en couches et simplement une analyse intellectuelle logique avait, dès le début du Net, isolé la couche "physique" (cables), la couche communication physique (sockets), puis la couche TCPIP (protocole de comm), et enfin la couche appli, permettant ainsi la fabrication de serveurs/clients basés sur des bibliothèques isolées (voir X11 par exemple, mais tout serveur unix jusqu'au début des années 2000 tout au moins), en particulier du point de vue de l'a-synchronicité, jusqu'au début des années 2000 tout au moins les sockets asynchrones sur Windows (WSAsync) nécessitaient pour fonctionner un handle de fenêtre, travsersant ainsi les couches, violant le modèle ISO, et interdisant donc une séparation entre IHM et couche de transport... Et les devs de M$ en étaient fiers, spécifiant dans les documents systèmes que c'était un grand avantage de Win de pouvoiir envoyer des messages aux fenêtres....

[Ecosmose]

De rien

Disons que les "modèles" MVC et autres , en formalisant la couche C comme un "pattern", est à mon avis défaillante dans la mesure (et il suffit de voir sur ce forum) où on ne précise pas l'effort de conception impliqué pour séparer l'IHM du reste...

L'effet Internet et client léger y est aussi pour beaucoup...

Un excellent exemple de mauvaise séparation fût (je ne sais pas si ça a changé) les bibliothèques sockets sous Windows :
....
jusqu'au début des années 2000 tout au moins les sockets asynchrones sur Windows (WSAsync) nécessitaient pour fonctionner un handle de fenêtre, travsersant ainsi les couches, violant le modèle ISO, et interdisant donc une séparation entre IHM et couche de transport... Et les devs de M$ en étaient fiers, spécifiant dans les documents systèmes que c'était un grand avantage de Win de pouvoiir envoyer des messages aux fenêtres....

Excellent Merci pour ce 'devoir de mémoire' comme quoi l'adage "Dites ce que je dis, faites pas ce que je fais" s'applique aussi au plus gros !