AILES : Architecture, un tour d'horizon des points de vue

Point de vue
    Pour rappel, les architectures, quand elle sont désignée par leur point de vue (comme "Architecture Technique" et "Architecture Fonctionnelle"), désignent des architectures selon un point de vue technique ou d'un point de vue fonctionnel.
    Il s'agit de "vue architecturale" introduite dans l'article sur la définition de l'architecture et détaillée dans celui sur les caractéristiques de bases : Vues.
    Une vue architecturale modélise une ou plusieurs structures, chaque structure regroupant des éléments d'un même domaine architecturale. Par exemple, la vue "fonctionnelle" (détaillée ci-dessous) regroupe surtout des éléments de type "acteur" et "cas d'utilisation".
    En utilisant un point de vue, on peut tout aussi bien représenter:
- la vue logique d'une classe java ou C++ (ce qui est l'utilisation majeure de tout AGL, via UML);
- la structuration de services métiers (et là, on rentre dans le domaine des sphères architecturales).
    En gros, avec un point de vue, on peut tout représenter. Avec une sphère, on recentre son intérêt sur une véritable activité d'architecture: la structuration de concepts.
    Ce qui suit détaille les différents points de vue couramment utilisés. Encore une fois, on retrouvera ces points de vue aussi bien au niveau d'un projet que d'une sphères architecturales.

2 points de vue majeurs : fonctionnel et technique
    Si vous vous retrouvez dans des départements d'architecture, notamment présent dans des "DSI" (Direction des Systèmes Informatisés, qui ont pour mission d'établir les grandes recommandations aux chefs de projet des différentes filiales ou départements), vous constaterez 2 unités reliées à l'architecture : A.F. et A.T., à savoir Architecture Fonctionnelle et Architecture Technique.
    En effet, l'article sur la définition de l'architecture le mentionne clairement : lorsque l'on parle de ce domaine en terme général et global, on parle de « l'architecture du système logiciel » (System Software Architecture).
    Ce "système logiciel" est la somme :
- d'une infrastructure technique, matérielle avec ses contraintes de temps de réponse, capacité réseau et autres "tenue de montée en charge" : il s'agit de l'architecture technique ;
- d'un ou plusieurs composants logiciels, avec ses flux métier, son vocabulaire propre et ses connecteurs pour traduire les flux hétérogènes venant de systèmes logiciels externes.
    Au passage, le consultant de 30 ans est formel : c'est quand on passe de l'AF (du fonctionnel) à l'AT (au technique) qu'on rigole. Passer d'une conception de haut niveau à la réalité matérielle et "connectique" du terrain réserve des surprises... (cf. l'article De l'AT vers l'AF et le contraire)
    Pour rappel, "Architecture Technique" et "Architecture Fonctionnelle" désignent des architectures selon un point de vue technique ou d'un point de vue fonctionnel. Il s'agit de "vue architecturale" introduite dans l'article sur la définition de l'architecture et détaillée dans celui sur les caractéristiques de bases : Vues.

8 points de vues
    Pour modéliser une architecture, on partira des 2 points de vues de base exposés en début d'article : fonctionnel et technique.
    Architecture Fonctionnelle :
    * point de vue fonctionnel : spécifie les besoins fonctionnels des utilisateurs. En UML, cela se traduit typiquement par des Use Case (cas d'utilisation), où les acteurs extérieurs au système logiciel sont identifiés, et les principaux services sont nommés. On considère le système logiciel lui-même comme une "boite noire".
    * point de vue logiciel : spécifie la dynamique du système logiciel, avec les interactions entre objets et les contraintes dynamiques. Le tout s'illustre via les diagramme de collaboration et de séquence en UML. Au contraire du point de vue précédent, on détaille complètement le système logiciel.
    * point de vue structurel ou statique : organise le modèle des besoins fonctionnels en package et classe. Cela correspond à l'activité d'analyse des spécifications.
    * point de vue logique : détaille le point de vue précédent en allant jusqu'aux classes de conception préliminaire
Ces deux points de vue utilisent principalement la vue UML la plus connue des développeurs, le diagramme statique des classes.
    Architecture Technique :
    * point de vue matériel : illustre les choix et la topologie matérielle choisie, avec toute la problématique des connexions physiques, du dimensionnement des processeurs et des bandes passantes.
    * point de vue de déploiement : localise les composants d'architecture sur le réseau physique.
Ces deux points de vue (matériel et de déploiement) se synthétisent en UML par le diagramme de déploiement, dont un exemple est fourni dans l'article sur la définition de l'architecture.
    * point de vue configuration logiciel ou physique : décrit la façon dont les composants logiciels identifiés par le point de vue logique se construisent techniquement. C'est le passage d'une notion logique abstraite (comme une classe) à un élément concret "physique" (un "cpp" et un "header", en C++, ou encore une librairie, ou un exécutable... telle que défini dans caractéristiques de bases). En UML, cela correspond au diagramme de "composant" (à prendre ici au sens de "élément "...).
Cf. aussi - dans le Questionnaire Langage - les réponses concernant la notion de Composant.
    * point de vue d'exploitation : fait le lien entre les composants physiques concrets du point de vue précédent et les fonctionnalités du logiciel (telle librairie prend en charge telle fonction). Le but étant d'assister les ingénieurs d'exploitation (lorsque le système logiciel tourne en "prod" - en production) afin qu'ils identifient rapidement l'élément défaillant et fassent une remontée d'anomalie efficace. En UML, le diagramme de composant mélange les points de vue physique (évoqué juste avant) et d'exploitation.
    On notera que l'aspect "exploitation" est rarement perçu par l'ingénieur d'étude. Il conçoit, programme, livre mais il faut qu'il reste suffisamment longtemps sur une mission pour en assurer la maintenance. C'est alors à ce moment qu'il s'aperçoit s'il peut vraiment retrouver le composant fautif lorsqu'un bug lui est remonté...
Pour résumer le lien entre les diagrammes UML et ces points de vue, [UMLAction] nous propose le tableau suivant (revu et interprété, et aussi complété en faisant apparaître les points de vue majeurs "fonctionnel" et "technique") : en rouge (x), les diagrammes principaux correspondant à un point de vue, en noir (x), les diagrammes secondaires utilisés par ces mêmes points de vue.

Points de vue	AF (architecture fonctionnelle)				AT (architecture technique)
Points de vue	fonctionnel	logiciel	structurel	logique	matériel	déploiement	config.log.	exploitation
Dgr. UML
use cases	x	x
séquence	x	x		x
collaboration	x	x		x
classes	x	x	x	x
objets			x	x
états			x	x
activités	x	x
composant						x	x	x
déploiement					x	x

(Rappel, la notion de "composant", dans le diagramme UML de composant, est à entendre au sens de l'élément concret défini dans caractéristiques de bases).
    On notera qu'UML offre beaucoup d'outils pour modéliser une architecture fonctionnelle, mais tout le monde s'accorde à dire que le formalisme proposé pour l'architecture technique est encore trop pauvre pour l'instant (2001, UML1.3).

4 architectures majeures : multi-tiers, multi-niveaux, couches, composants
    Ces architectures peuvent s'appliquer soit à la partie fonctionnelle (pour mieux répartir et structurer les fonctions) et/ou à la partie technique (pour mieux répartir et structurer les composants et le matériel).
    Elle sont présentées brièvement puis mise en correspondances avec les 8 points de vue présentés ci-dessus :

    architecture client/serveur, dite "multi-tiers" (pour rappel, "tier" signifie niveau). Elle met en ouvre un client qui communique à un serveur de données ou de services.
cf. l'article sur les 4 grandes sphères architecturales pour une description détaillée.
=> c'est avant tout une architecture technique, qui indique comment distribuer des services. Elle décrit donc une architecture applicative.
Rq : le synonyme "niveau" n'est pas correct, car un niveau est plus proche de "layer" (cf. ci-dessous, et cf. également Questionnaire Architecture : Layer vs. Tiers)

    architecture multi-niveaux (multi-layers) va de pair avec la précédente. Elle décrit où se situent les différents services fonctionnel.
cf. l'article sur les 4 grandes sphères architecturales pour une description détaillée.
=> c'est une architecture fonctionnelle, qui aide à positionner les services fonctionnels par niveau
=> c'est avant tout une architecture technique, qui indique avec quoi (quel type de matériel - central, poste utilisateur, etc... -) distribuer des services.

    architecture en couches établi la correspondance entre les services techniques et les composants d'architectures concernés (comme un middleware, plus un driver), via des cas d'utilisation technique.
cf. l'article sur les 4 grandes sphères architecturales pour une description détaillée.
=> c'est avant tout une architecture technique, qui indique comment structurer des services par exemple, en découplant la présentation de la logique applicative) . Elle décrit donc une architecture applicative (lien).

    architecture à base de composant identifie des composants architecturaux réutilisables.
cf. l'article sur les 4 grandes sphères architecturales pour une description détaillée.
=> c'est une architecture fonctionnelle, qui indique quoi identifier comme services réutilisables (composant vu comme une entité fonctionnelle).
=> c'est aussi une architecture technique, qui comment structurer ces services sur le plan applicatif (composant vu comme une entité technique)

Les architectures selon leurs points de vues
    En réunissant ces 2 notions, on retrouve les activités suivantes, également proposé par [UMLAction] et remis en forme par moi :

	Architectures	Multi-tiers	Multi-niveaux	en couches	par composant
points de vue		Multi-tiers	Multi-niveaux	en couches	par composant
A F	fonctionnel		positionnement des acteurs et services aux différents niveaux de l'entreprise		identification des cas d'utilisation *métier* gérés par des composants existants
	logiciel			positionne des cas d'utilisation technique sur les différentes couches	identification des cas d'utilisation techniques gérés par des composants existants ou par une réutilisation d'un composant interne.
	structurel		regroupement des classes par niveau		regroupement des classes provenant de composants existants
	logique			identification des classes se situant dans la même couche de service technique	regroupement des classes communes au même composant
A T	matériel	choix d'un middleware capable de distribuer les services	définition des matériels installés par niveau
	déploiement	regroupement des composants par service distribué	définition des postes de travail par niveau		identification et positionnement des composants d'exploitation sur le réseau
	config. log. ou "physique"	fabrication des composants distribués		fabrication des composants spécifiques à une couche	fabrication de chaque composant
	exploitation	répartitions des composants entre tiers	regroupement des composants par poste de travail	répartition des composants par couche	identification des interfaces et des composants à exploiter

    A la lecture de ce tableau, on réalise la difficulté d'établir une architecture... puisque cette dernière est souvent un mélange des 4 architectures de base présentées dans cet article.
    A l'évidence, on retrouvera presque toujours une architecture de type "multi-tiers", car tout le monde, de nos jours, est "client" d'un service logiciel donné, mais est aussi "serveur" vis à vis d'autres composants. Mais on remarquera que cette architecture reste essentiellement "technique".
    Pour modéliser les flux d'information et services métiers, on parlera des niveaux (si l'application est plus qu'un logiciel local mono-utilisateur mono-poste), mais aussi couches (pour bien découpler techniquement les différentes responsabilités logicielles) et composants (car il est de plus en plus difficile de "tout" réinventer à chaque fois!).