AILES : AF, Architecture Fonctionnelle, principes généraux

Sphère et Point de vue
    Plus encore que d'autres sphères, il est important de distinguer l'Architecture Fonctionnelle considérée comme un point de vue (et présentée ici : Architecture Fonctionnelle), de la sphère.
    L'article sur les sphères architecturales rappelle la principale différence entre les 2 notions :
- un point de vue modélise une ou plusieurs structures (des éléments d'un même domaine architecturale) ;
- une sphère définit la nature de ce que ces structures vont modéliser: ici la nature des éléments modélisés représentent les interfaces et la dynamique d'un système, mais certainement pas une implémentation concrète ou des de grands concepts métiers.
    Or le point de vue Fonctionnelle est aussi bien axé développement de projet que architecture en tant que sphère. C'est-à-dire que l'interface fonctionnelle définie en utilisant le point de vue fonctionnel pourrait aussi bien servir à générer une classe bien concrète que, et là on retrouve le domaine de la sphère architecturale, modéliser et structurer des services métiers, sans préjuger de leur implémentation finale (qui sera fortement influencée par le fait que ce service métier soit distribué ou non, avec ou non un stub et un skeleton, etc...).
    Ici, la différence entre le point de vue Architecture Fonctionnelle et la sphère Architecture Fonctionnelle est donc frappante. On peut utiliser le point de vue dans tout AGL supportant UML pour exprimer autant des concepts et des process métier (au travers de classe très générales d'analyse)., mais aussi des concepts, interfaces et cas d'utilisation fonctionnels qui traduisent le métier, comme l'illustre le diagramme suivant.

Le système
    Une des premières difficultés de cette sphère architecturale réside dans la définition de système, des ses limites et des acteurs.
    La limite du système se déduit des services qu'il fournit à ces composants externes au système et qui en attendent un retour bien précis. Ces composants externes sont les acteurs, et il faut bien grader à l'esprit qu'ils ne sont pas forcément humain: une imprimante peut très bien être un acteur vis-à-vis d'un système (la paie des salariés) qui lui rend un service (le déclenchement à date fixe de l'impression des bulletins de paie).
Un acteur ([Longepe]) représente 'ce qui existe en dehors du système' et interagit avec lui. Un acteur opère des transactions avec le système et chaque séquence de transactions peut être définie dans un cas d'utilisation.
Un acteur est différent d'un utilisateur:
- un utilisateur est quelqu'un qui utilise réellement le système;
- un acteur est un agent externe qui représente quelque chose pour le système.
    3 types de systèmes seront mis en évidence [Longepe]:
- le front-office: l'ensemble de services orientés client activables directement par l'acteur externe en contact avec le client ou par le client lui-même;
- le back-office: l'ensemble des services orientés produits, non activables directement par l'acteur externe en contact avec le client ou par le client lui-même;
- le middle-office: l'ensemble des services non activables directement par l'acteur externe en contact avec le client ou par le client lui-même et permettant:
    * une interaction directe avec le client;
    * la correspondance entre les vues client (front-office) et produit (back-office).
    On n'oubliera pas de commencer à détailler les services attendu en terme de accès au système (les connections), qui devront supporter l'activation des services au travers de différents canaux. Les services accessibles seront alors, par exemple :
- complet, riche en contenu dans le cadre de liaisons en mode connecté (directement au système);
- sécurisés et personnalisés dans le cadre de liaisons en mode distant.

Lien métier-fonctionnel
    Ce lien part des activités définies par l'Architecture Métier, et arrive au final à des cas d'utilisation.
    L'activité, rappelons-le, constitue une étape d'une procédure métier, elle-même présente pour assurer la réalisation d'un objectif métier.
    De cette activité, on peut en déduire des fonctions, qui à haut niveau restent des macro-fonctions. Plus on détaille ces fonctions, plus on se rapprochent de "fonctions élémentaires" ou fonctionnalités, que l'on peut mettre en correspondance bijective avec les services du SI.
    Ainsi l'objectif 'ventes de produits sur site web' implique la procédure 'commande' qui comprend les activités 'Sélection du produit', 'affichage des produits sélectionnés', 'Saisie des données complémentaires', 'Contrôle', 'Validation', 'Envoi de la commande', 'Mise à jour des systèmes connexes'.
=> De l'activité 'Sélection du produit', on peut déduire les macro-fonctions 'Consultation de la liste des produits', 'Choix du classement des produits' (par prix, taille, poids, etc...), 'Choix du produit'.
=> De la macro-fonction 'Consultation de la liste des produits', on peut en déduire la fonctionnalités (et donc le service du SI) 'lister produit(critère)' du composant métier 'Produit'.

Les cas d'utilisation
   En reprenant l'ensemble des services définis précédemment, les cas d'utilisation vont permettre de représenter la façon dont l'acteur (extérieur au système, et qui peut être un simple utilisateur comme un périphérique) perçoit le SI par rapport à chacun de ses besoins.
    Ces cas d'utilisation vont correspondre selon les cas à:
- des procédures métier, en ce sens que l'on pourra, au travers d'un enchaînement de cas d'utilisation, reconstituer une procédure métier. Ainsi la procédure 'commande' peut se retrouver via les cas d'utilisation 'Saisie d'une commande', 'Validation d'une commande', 'Éditer un bon de commande';
- une ou plusieurs activités (donc à un sous-ensemble d'une procédure métier): le cas d'utilisation 'Saisie d'une commande' regroupe les activités de 'Sélection du produit', 'affichage des produits sélectionnés', et 'saisie des données complémentaires'.
- a des messages (un message utilise un services qui est une fonction du SI). Ainsi, le cas d'utilisation 'Éditer un bon de commande' représente à un niveau plus détaillé l'activité 'Mise à jour des systèmes connexes'.


Pourquoi ?
    Il s'agit vraiment de 'donner vie au métier', et pour cela deux approches sont possibles:
- une approche 'Top Down': on part de la feuille blanche et l'on déduit tous les fonctionnalités, tous les services métiers nécessaires;
- une approche 'Bottom-Up': on part de l'existant, afin d'éviter toute régression. L'idée est que le système doit assurer au minimum les services existants.
    De ces démarches, on doit établir les invariants entre les procédures logiques ainsi mises en évidence, de façon à mutualiser au maximum ces fonctionnalités.
    Il s'agira ensuite de:
- regrouper ces fonctionnalités au sein d'application;
- de compléter ces services métier par des services techniques.
Tout cela se détaille au sein des sphères d'Architectures Applicative et Technique.