Les couches offrent les avantages suivants :
-
Les couches aident à apporter des attributs qualité de modifiabilité et de portabilité à un système informatique.
Une modification d'une couche inférieure qui n'affecte pas son interface ne requiert aucune modification d'une
couche supérieure. Par exemple, un serveur d'applications conforme à la norme J2EE™ peut être librement remplacé
sans modification du logiciel de niveau applicatif. Une modification d'une couche supérieure qui n'affecte pas les
fonctions qu'elle requiert des couches inférieures n'affectera aucune couche inférieure. En général, les
modifications d'un système logiciel en couches qui n'affectent aucune interface sont limitées à une seule couche.
-
Les couches font partie du rôle de plan que joue l'architecture dans la construction du système. Connaissant les
couches dans lesquelles se trouve leur logiciel, les développeurs savent quels services ils peuvent utiliser dans
l'environnement de codage. Les couches peuvent définir des affectations de travail pour les équipes de
développement (mais pas toujours).
-
Les couches font partie du rôle de communication joué par l'architecture. Dans un grand système, le nombre de
dépendances parmi les modules s'accroît rapidement. L'organisation du logiciel en couches avec des interfaces
constitue un outil important pour gérer la complexité et communiquer la structure aux développeurs.
-
Les couches aident au rôle d'analyse joué par l'architecture. Elles peuvent être utilisées pour l'analyse de
l'impact des modifications de la conception.
Les couches peuvent être strictes ou non strictes. Dans un schéma de couches strictes, les composants peuvent
uniquement utiliser des composants dans la ou les mêmes couches situées immédiatement dessous. Dans un schéma de
couches non strictes, les composants peuvent utiliser des composants dans la même couche ou dans toute couche
inférieure. Notez qu'en règle générale, toutefois, les composants ne doivent pas être autorisés à utiliser des
composants des couches supérieures. Si des composants ont des dépendances sur des composants des couches supérieures,
il devient alors difficile de remplacer les composants des couches supérieures sans avoir à modifier les composants des
couches inférieures. Pour plus d'informations, y compris sur les techniques de modélisation des couches, voir Concept : Partitionnement de solution.
Un point important à noter est que les couches logicielles sont différentes des niveaux. L'affectation à des machines
dans un environnement réparti, le flux de données dans les éléments et la présence et l'utilisation de canaux de
communication ont tous tendance à être illustrés dans des figures de niveaux qui peuvent être confondues avec des
diagrammes de couches. Les diagrammes de niveaux montrent plutôt des flèches à deux sens, indiquant une communication
bidirectionnelle d'un type donné. La communication bidirectionnelle (symétrique) n'est pas bon signe dans un diagramme
de couches. En outre, l'attribution d'un composant à un niveau est basée sur les règles de positionnement prises en
compte lors de la définition de l'architecture opérationnelle et elle est définie par les caractéristiques de niveau de
service requises par le système. La différence principale entre les diagrammes d'organisation en couches et les images
de niveaux est que les premiers ne comportent pas de notion de positionnement alors les secondes en tiennent compte.
Règles empiriques d'organisation en couches
-
Tous les composants qui fournissent une fonctionnalité métier indépendante des applications peuvent être disposés
en une seule couche. Les fonctions métier indépendantes des applications sont, par exemple, la "gestion client" et
la "gestion des produits" qui s'appliquent à une gamme d'applications différentes.
-
Tous les composants qui fournissent des fonctions techniques telles que le traitement d'erreurs,
l'authentification, la consignation et l'audit peuvent être placés dans une autre couche (logique). Ces composants
sont indépendants du métier et des applications. Dans certains cas, la proximité entre des composants techniques et
fonctionnels peut nécessiter leur placement dans une couche commune. Il s'agit de décisions liées à l'architecture
et elles doivent être documentées en tant que telles.
-
Les composants intermédiaires tels que la mise en file d'attente de messages et le logiciel SGBD relationnel
peuvent être placés dans une autre couche. Cela est également désigné par le terme "Matrice".
Exemple
Voici une vue en couches d'une architecture SOA montrant les couches standard (et recommandées) des différents éléments
présents dans une solution.
Dans ce schéma d'organisation en couches, il est assez simple de déterminer où nos composants doivent être placés ;
nous plaçons les composants associés à notre exemple d'agence de location de véhicules dans la couche Composants de
service, comme illustré ci-dessous. Notez que nous souhaitons utiliser des couches strictes dans notre modèle,
nous utilisons donc une composition UML contenant nos composants dans la couche Composants de service et nous exposons
uniquement la fonctionnalité des composants de service à l'aide de ports délégués où le port fournit la même interface
que le composant de service même.
|