Architectures d’application

Couches

Les couches (ou layers) d’un système sont des sous-systèmes à part entière qui consomment des informations provenant de leur environnement et lui en fournissent. L’objectif de l’empilement des couches logiques est d’isoler les responsabilités au sein de packages d’une même catégorie.

On parlera de layer strict ou unidirectionnel dès le moment où les dépendances se font du bas vers le haut, c’est-à-dire qu’on a besoin de la couche inférieure pour compiler la couche supérieure (et que la couche inférieure ne connaît rien des couches supérieures). Procéder de la sorte est efficace car cela limite l’effet spaghetti dans le code, interdit quasiment les dépendances cycliques entre packages (et donc, minimise les impacts d’un changement dans une couche) et limite le temps de compilation ou d’interprétation.

Enfin, si on veut rendre les couches interchangeables, il est nécessaire de définir ou d’utiliser un protocole de communication.

Figure 7.1 : Architecture multicouche

Tier

La stratification logique offre de nombreux avantages en termes de génie logiciel (modularité, maintenabilité, découplage, parallélisme, réutilisabilité...). Toutefois, si on veut garantir une indépendance forte des couches logiques, il faut que cette stratification opère aussi au niveau de l’environnement d’exécution du code. Ainsi, chaque couche d’architecture correspondra en réalité à un déploiement physique particulier. Nous allons ici expliciter l’évolution historique de la structure monolithique vers le quasi-standard n-tier et nous détaillerons celui-ci.

Traditionnellement, les architectures multiniveaux (ou n-tier) sont des applications client/server dans lesquelles la présentation, la logique applicative et les accès aux données s’exécutent dans des couches distinctes.

MVC

Il est nécessaire de clarifier les différences qu’entretient ce pattern architectural avec celui des architectures n-tier, car leur proximité conceptuelle est si ténue qu’elle peut induire des confusions. Comme le modèle n-tier, le modèle MVC, ou modèle-vue-contrôleur, sépare le design en trois zones : la présentation, la logique et les données.

Applications mobiles

L’avènement récent des smartphones et autres tablettes inflige une mutation violente au paysage logiciel. On assiste à une rétroaction technologique, car les terminaux mobiles imposent paradoxalement des contraintes qu’on croyait définitivement enterrées à l’heure des processeurs multicœurs : un espace mémoire limité tant à l’exécution qu’au stockage, des résolutions d’écran minuscules, plus faibles que celles des écrans cathodiques, une vitesse de traitement en deçà des ordinateurs bas de gamme.

Les plateformes mobiles imposent des exigences non fonctionnelles drastiques (bande passante, résolution d’écran, déploiement via les stores d’Apple ou de Google par exemple) qui nécessitent de repenser les architectures traditionnelles. Cet effort d’adaptation technologique se verra largement récompensé par l’accession à un marché colossal : pléthore d’utilisateurs ultra-connectés, avides d’information et autant de cartes de crédit à portée de clic.

Alors, comme on peut dire que les technologies d’entreprise sont stabilisées dans l’arène n-tier où s’affrontent les technologies d’Oracle et de Microsoft jugulées par les règles...

Exemple

Nous allons illustrer les points précédents par une implémentation très simple suivant le modèle MVC sur une architecture 3-tier en Java EE. Il s’agit simplement d’illustrer les interactions entre la vue, le contrôleur et le modèle dans un processus d’achat en ligne via la commande d’un panier.