AILES : Architecture Fonctionnelle (AF)

Rappels
    Le terme "Fonctionnelle" de l'AF désigne un des 2 points de vues majeurs de l'Architecture.
On se souviendra que le "point de vue", tel que présenté dans caractéristiques de bases : Vues, désigne la modélisation d'une ou plusieurs structure, chaque structure est un composant particulier représentant une partition d'éléments appartenant à un même domaine.
    Bon ok, je donne un exemple :
    Dans l'article sur les points de vue des architectures, le point de vue majeur "Fonctionnel" est décomposé en 4 vues : fonctionnelle, logicielle, structurelle et logique.
    Ainsi, par exemple, la vue logique a-t-elle comme composant particulier des structures composées de classes logiques (éléments concrets d'architecture appartenant au même domaine d'architecture "Classe"). Le diagramme UML associé est celui, bien connu, du diagramme de classe. Vous trouverez d'autres exemples dans l'article sur les caractéristiques de bases de l'architecture, notamment avec le point de vue "Cas d'Utilisation" ("Use Case").
    En examinant les 4 vues déjà citées comme constituant l'AF, on peut en déduire que celle-ci spécifie les besoins fonctionnels de l'utilisateur (vue fonctionnelle, Use Case), en en décrivant la dynamique (vue logicielle, diagramme de séquence), favorisant la décomposition du système logiciel en sous-systèmes lors de l'analyse (vue structurelle, diagramme de classe), afin d'aller jusqu'à la modélisation de ce système sous forme de classes (vue logique, diagrammes de classe et d'objet).
    Toutefois, la granularité retenue au niveau de l'AF est rarement la classe, instrument de modélisation trop fin. Il faut ici introduire la notion de "composant", sous-entendu "composant fonctionnel métier", sachant qu'un composant de ce type rempli toujours 2 contrats :
- un contrat technique qui supporte l'exécution de la fonction métier du composant (avec, par exemple, la notion de "nommage" ou "désignation" qui permet de le retrouver via un serveur de composant) ;
- et un contrat fonctionnel, qui permet de délivrer le service métier au travers d'une interface (on détaillera la partie technique dans un prochain article sur la populaire "approche composant", mais il sera également présenté dans un futur article sur l'Architecture Technique).
    Ce composant particulier (puisque composant "fonctionnel métier"), comme tous les composants, est composé d'éléments d'au moins 2 types :

1/ des classes (dont une est une interface), ce qui donne la modélisation classique du composant en UML : - un package représentant le composant, et contenant - une interface, classe publique qui exporte les services du composant ; - une classe d'implémentation interne au package, qui peut se servir d'une ou plusieurs classes privées.
2/ des éléments techniques (process, main, librairies,...) qui supportent l'exécution du service métier en lui garantissant persistance, distribution, sécurité, etc...	ces éléments font parti du Composant Technique, tel que présenté dans l'article sur l'Architecture Technique.

Ce qui suit utilise donc la notion de composant au sens métier du terme et ne parle que de son contrat fonctionnel, sans aborder son contrat technique.

Ce que n'est pas l'AF
On trouve souvent l'une de ces 2 présentations en tant que "architecture fonctionnelle".

schéma a

schéma b

    Il s'agit plutôt de considérations technico-fonctionnelles, dont on verra une présentation beaucoup plus détaillée dans l'article illustrant la "projection" qui existe entre architecture fonctionnelle et technique. On trouvera un exemple d'une telle "architecture" soit disant fonctionnelle dans l'exemple illustrant le passage de l'AF vers l'AT. Cet exemple utilise, comme dans les schémas a et b, des composants (tels que modélisés en UML) ci-dessus, mais on peut voir ce type d'architecture "pseudo-fonctionnelle" avec d'autres types d'éléments (comme des composants techniques, justement, pour représenter des accesseurs de données).
     Ce type d'architecture est à mi-chemin avec une architecture applicative. En effet, dans une architecture applicative, on ne retrouve pas de composant fonctionnel métier, mais bien des composants techniques.
     Le niveau "Données" représente les bases de données et les fichiers du Système d'Information.
    Le niveau "Application" représentent tous les traitements réalisés sur les données :
- lorsqu'il est seul (schéma a), il est caractéristique d'environnement de développement de type VisualBasic. Les traitements fonctionnels (règles de gestions) sont fortement imbriqués avec les traitements de présentation. En plus des problèmes de déploiement et d'évolutivité que cela entraîne, ce niveau est trop peu structurant : il ne distingue pas entre ce qui est générique et réutilisable dans une application et ce qui ne l'est pas ;
- cette dernière remarque reste vrai dans le schéma b, où la présentation est - heureusement - découplée de l'application.
    Si l'on se concentre sur la notion de "composant" (délivrant un service au sens fonctionnel du terme), il ne faudrait pas y inclure dans l'architecture fonctionnelle des services génériques participant à l'infrastructure technique d'exécution de ces mêmes composants, comme la persistance ou la gestion de la transaction, ou encore le caractère distribué d'un composant, sa sécurité, etc. Comme l'article sur le passage de l'AF vers l'AT le détaillera, ces services-là font parti du contrat technique que doit remplir le composant. Or seul son aspect "métier" (fonctionnel) nous intéresse ici, comme précisé au début de cet article. Et la présentation soit-disant "fonctionnelle" de cette architecture telle que présentée ci-dessus ne manque pas de faire intervenir ces composants techniques, notamment pour l'accès aux données.
    Ces deux aspects (peu structurant et composants techniques) contredisent la qualité fonctionnelle que l'on veut prêter à ce découpage. On lui préférera l'organisation à 3 niveaux présentée dans le paragraphe suivant.

Une architecture fonctionnelle à 3 niveaux
Le schéma suivant présente une première structuration des composants fonctionnels qui composent toute application.

+ une description de la dynamique d'enchaînement des composants
(diagrammes de séquence et/ou d'états)

    Le niveau présentation correspond bien sûr à l'affichage, la gestion des interactions et de la mise en forme des informations en provenance et/ou à destinations de l'application. Ce niveau correspond aussi à de nombreux services génériques pérennes, comme de nombreux composants dédiés à l'affichage (d'une date, d'une somme, etc...), mais aussi l'activation ou l'interruption d'une commande de l'application ("valider", "annulez", ...).
    Un niveau "Métier" qui regroupe les composants génériques des différents domaines de l'entreprise. On retrouve les composants généraux partageables par plusieurs sous-systèmes du système d'information global : des composants de types "entités" ou "ressource" (par exemple les objets "Client", "Employé", "Commande", ...)et des composants de type "processus" ("PriseDeCommande") qui mettent en jeu plusieurs entités.
    Le niveau "Application" regroupe les composants non génériques, soit les composants associés à des besoins applicatifs non-généralisables au niveau de l'entreprise, en particulier les composants de contrôle qui gèrent les interactions entre la "Présentation" et le "Métier", ce qui constitue toute la "logique applicative".
    Face à un tel modèle, 2 remarques s'imposent :
    1/ On notera que ces composants se modélisent naturellement en utilisant un paradigme objet, exposant ses services via son interface, son mécanisme interne étant encapsulé dans son package, comme cela est représenté dans le premier schéma de l'article, en notation UML. Pourtant, rien n'empêche son implémentation dans des langages non-objets comme le COBOL (très courant!).
    2/ Ce découpage en trois niveaux peut rappeler le paradigme "MVC" (Model-View-Controler ou Modèle-Vue-Contrôleur).
Toutefois, en MVC, la partie "Présentation" n'a pas accès à la partie Modèle, afin de pouvoir faire évoluer cette dernière indépendamment de la première (et inversement).
Or la répartition des composants en 3 niveaux "Présentation-Application-Métier" est plus souple. En particulier, les composants génériques réutilisables de la couche "Métier" sont justement conçus pour être stables (leur interface n'évolue pas, même si le mécanisme interne peut subir d'importantes évolutions). Donc ces composants peuvent très bien être utilisés sans risque majeur par la couche "Présentation".
(Concrètement, c'est ce qui se passe lorsque, dans l'architecture J2EE, la page jsp "Présentation" récupère le composant "Client" de la couche "Métier" pour en afficher le nom, tout cela via une servlet et certains beans java applicatifs qui ont mis le-dit composant métier "Client" dans l'objet "Session" ou "Request").

La nécessaire évolution des architectures fonctionnelles
    Le réseau était, avant Internet, peu facile à développer et à mettre en relation avec d'autre réseaux. Il en a résulté :
- une sédimentation des couches fonctionnelles développées (par exemple, chaque type de produits différents vendu par une entreprise a son propre système de prise de commande et de livraison) ;
- une adhérence géographique (par exemple, chaque région a son propre système de gestion des clients, ce qui est plus facile que de tout centraliser tout le temps) ;
- une dispersion et émiettement fonctionnel, une redondance des données (ce qui est la conséquence directe des 2 premiers. Les données se trouvent dupliquées, avec tous les risques d'incohérence et de déphasage que cela comporte).
    Aujourd'hui, on raisonne plus en terme de composant représentant des "services immatériels" (donc le plus souvent des logiciels ou encore un enchaînement "d'appels de services"), ce qui estompe la traditionnelle frontière entre réseau et le système logiciel considéré (le réseau tend à être de plus en plus masqué : on "accède à un service", peut importe qu'il soit distant ou non).
    De plus, les données et leur descriptions associées (méta-données) sont moins redondantes (donc moins nombreuses, mieux gérées, supervisées et structurées), remises à jour beaucoup plus régulièrement et masquées aux utilisateurs (là encore, on accède plus à un service qu'à une donnée).
    L'architecture fonctionnelle passe de plus en plus par une urbanisation indispensable, à savoir :
- identifier les données et leurs services associés ;
- associer l'ensemble des processus de gestions associé au système dans lequel ce composant évolue (workflow, data-mining, SI, etc...), afin d'en constituer une véritable cartographie (où le composant intervient-il et dans quel processus ?). Le composant "Client" d'une société peut en effet se retrouver impliqué dans un grand nombre de processus... avec des risques de redondances et d'incohérences déjà évoqués.