AT (Architecture Technique)

[Architecture]
[SEI], [RDFranceTelecom], [BAF99]

1/ des éléments techniques (process, main, librairies,...) qui supportent l'exécution du service métier en lui garantissant persistance, distribution, sécurité, etc...     Tous ces éléments participent à la définition d'un composant technique.     On notera que, en UML, le composant technique présenté dans cet article se modélise avec le symbole utilisé par "ma librairie". Les 2 autres symboles sont des éléments techniques.

Exemple de composant technique : une librairie dynamique, basée sur les spécifications (les headers) de plusieurs classes.

2/ un lien avec un besoin fonctionnel (métier ou technique), qui peut prendre la forme d'une ou plusieurs classes.     Ces classes peuvent être organisées sous forme de Composant Fonctionnel. Ces liens se retrouvent aux travers les points de vue physique et d'exploitation.     Tout composant technique (dit aussi "physique") est donc relié à un composant fonctionnel (dit aussi "logique"), la fonctionnalité supportée étant aussi bien "métier" (exemple : validerCommande()), que "technique" (exemple : sauverEnBase()). Certains AGL utilisent cette logique pour, en modélisation C++, relier la classe (logique) aux composants physiques (header ".h" et body ".cpp").

Exemple : cette librairie est "reliée" à un composant fonctionnel technique (et non métier, comme l'est le "composant").     Le lien de dépendance indique que le composant technique connaît le composant fonctionnel. Le contraire est faux : la fonctionnalité n'a aucune idée de son implémentation technique (librairie, DLL, service distant, ...).     Il n'existe pas de vue UML pour l'exploitation, qui permettrait, comme le montre le "faux" diagramme UML ci-contre, de bien visualiser les classes logiques "réalisées" par un composant physique.

Des composants techniques pour quoi faire ? Point de vue "ingénierie"
    On vient de le voir, un composant technique supporte un composant fonctionnel. Le besoin fonctionnel concerné peut aussi bien être purement métier que technique. Si l'on ne considère que les "besoins fonctionnels techniques", on arrive à un "socle technologique" qui supporte l'application fonctionnelle.
    Ce point de vue est à la base de l'architecture applicative.
    Le point de vue ingénierie se focalise sur ces "besoins fonctionnels techniques" (dont des exemples concrets sont donnés juste après) permettant la répartitions des composants fonctionnels "Métier" et leur exécution.
    Il s'agit de l'agrégation de 2 des 4 points de vues techniques présentés en début d'article. Ce "point de vue agrégé" ("ingénierie") se représente plutôt par les points de vue physique et d'exploitation.
    Il permet d'exprimer les besoins d'infrastructure sans faire a priori de choix de fournisseur.  
On remarquera bien qu'on ne parle pas de choix de machine, de réseau ou de topologie dans les points de vue physique et d'exploitation, qui ne mettent en œuvre que des composants techniques.
    A force de réaliser des projets, on a identifié différents services techniques génériques transversaux qui permettent aux composant Fonctionnels présentés dans l'AF de fonctionner correctement, c'est-à-dire de délivrer le service métier attendu.
Ces services sont constitutifs d'une plate-forme technique d'exécution des composants.
   
    (Au passage, on reconnaît dans ce point de vue ingénierie les éléments issus des points de vue physique - avec le symbole UML du composant - et d'exploitation - chaque composant physique étant relié à un besoin fonctionnel. Ici, il s'agit d'une collection de besoins fonctionnels techniques)
    Parmi tous les services présents dans ce schéma, on attend au minimum les services :
- cycles de vie qui permet de gérer la création et la destruction des objets au cours de la vie d'une application ;
- désignation qui permet de retrouver une interface d'un objet à partir d'un nom ;
- persistance qui permet d'assurer la rémanence d'un état au cours du temps ;
- transaction (commit, rollback, ...) qui permet d'assurer l'atomicité d'un traitement réparti (en concurrence avec d'autres) tout en garantissant l'intégrité du système (rq, ce n'est pas toujours obligatoire d'assurer ce service, surtout dans un cadre de consultation de données sans mise à jour) ;
- gestion de la concurrence d'accès qui permet de gérer de manière souple l'exécution simultanée de requête sur le même objet ;
- événements qui permet de découpler l'émetteur et le récepteur d'un message dans une communication asynchrone ;
- sécurité qui assure la sécurité des interactions entre les objets du système ;
- configuration et administration qui facilite l'exploitation de l'infrastructure d'exécution des composants qu'elle héberge.
    Cette plate-forme peut :
- soit exister et être mise en oeuvre sans programmation supplémentaire au niveau du composant fonctionnel (c'est la cas de certains services de l'architecture J2EE) ;
- ou au contraire nécessiter la programmation explicite de classes complémentaires. L'article sur le guide d'architecture en propose un excellent exemple au niveau de la persistance : il suffit de préciser dans la modélisation UML qu'une classe est persistante pour que automatiquement se rajoutent les classes purement techniques de gestion de la persistance.
    Cette dernière remarque souligne bien l'absence de pré-requis quant à la nature de ces composants techniques : ils sont aussi bien des composants objets java (J2EE) que des modules COBOL ou des classes C++ générées automatiquement (comme c'est la cas dans l'exemple de la persistance ci-dessus).
    Ces composants techniques englobent donc aussi bien les systèmes existants (legacy, dont le poids reste important, dixit cet ingénieur de 30 ans) que les nouvelles applications.

Des composants techniques pour quoi faire ? Point de vue "technologique"
     L'architecture technique s'est trouvée renforcée dans son importance avec la vague Internet et son architecture 3-tier (présentée dans l'article sur les architectures et qui est, rappelons-le, une architecture technique). Sun Microsystems déclarait en 1996 : "The network is the computer".
     Plus généralement, le point de vue technologique de l'architecture technique concrétise le passage des composants techniques évoqués dans le paragraphe précédent (comme par exemple la distribution) vers des choix techniques précis (comme par exemple, CORBA). Cela passe de la définition du poste client jusqu'à l'orientation et l'assemblage des composant en passant par le réseau.
    Il s'intéresse au choix précis des technologies matérielles et logicielles permettant de réaliser le système et aux choix d'organisation physique [machine, topologie, réseau]. Il est donc l'agrégation des points de vue matériel et déploiement.
    Ce point de vue est à la base de l'architecture technique (vue en tant que sphère architecturale)
    Pour mieux mettre un nom sur ces choix, il est utile de visualiser l'ensemble des paramètres qui vont influencer les décisions technologiques précises.
    C'est ce que propose ABAS [SEI] (Attribute-Based Architectural Style) qui détaille les attributs de l'architecture selon 3 de ces caractéristiques majeures : les stimuli, les paramètres architecturaux et les réponses. Chacune de ces 3 caractéristiques se détaille différemment selon le service générique transversal considéré : performance, évolutivité, persistance, sécurité, etc.
- les stimuli sont tout type d'évènement qui induit des changement dans l'architecture ;
- les réponses sont les effets mesurables de ces changements ;
- les paramètres architecturaux sont les aspects d'une architecture (composants, connecteurs et leurs propriétés) qui ont un impact direct sur la réalisation des réponses souhaitées.
    Ce qui suit est un exemple des attributs associés aux stimuli, paramètres et réponses du service performance.

    Pour ce besoin fonctionnel précis (la performance) :
- les stimuli sont les messages ou les entrées de l'utilisateur ;
- les décisions architecturales incluent le processeur et la gestion du réseau par des mécanismes concurrents ou non ;
- les réponses se caractérisent par des éléments quantifiables et mesurables comme le temps de latence.
    En interrogeant le client sur ses besoins en performance, on commencera à pouvoir faire des choix sur le type de matériel possible, le type d'OS (synchrone, asynchrone, multi-process ou multi-thread), etc. 
    En revanche, si l'on considère le service "évolutivité", les attributs sont différents : 
- les stimuli correspondent aux nombre et type de requêtes de modification du logiciel ;
- les réponses se quantifient en terme de nombre de composants, connecteurs et interfaces modifiés, ainsi que par l'effort fourni pour faire ces modification (nombre de personnes impliquées, temps passé, ...) ;
- les décisions d'architecture se basent sur des mécanisme d'encapsulation ou d'indirection qu'il faudra plus ou moins mettre en oeuvre suivant le type de stimuli et les réponses que l'on souhaite respecter. (Si le programme évolue régulièrement et que l'on a que peu de développeur, mieux vaudra dès le début prévoir une encapsulation importante afin de minimiser les effets de bords à chaque correction/évolution).
     L'implémentation de l'infrastructure d'exécution de composants peut alors se faire en choisissant le produit qui répond au mieux aux attributs identifiés ci-dessus.

Gestion des composants techniques
    La gestion de ces composants se fait par paliers : 
- paliers techniques qui regroupent la station, le réseau, le protocole et l'administration ;
- paliers applicatifs qui regroupent les messages (de préférence auto-descriptif en XML, donc évolutifs), plus les tests de stress ou montée en charge et les connecteurs techniques qui permettent de faire communiquer deux applications entre elles. Le tout est, dans l'idéal, réparti sur 3 niveaux :
    * TU (Test Unitaire) : concrètement, le poste du développeur ;
    * TIA (Test d'Intégration Applicative) : un environnement identique à la production, même type de machine, même nombre - réel ou simulé - d'utilisateurs, le tout dans une "salle blanche", constituée de machine aisément formatables et reconfigurables selon les applications à tester ;
    * Prod (mise en production et exploitation) : l'environnement réel du terrain, la fameuse "mise en production", couplée en principe avec un centre d'appel de niveau 1 (celui qui se ramasse les appels au secourt direct).
    Une telle gestion justifie par ailleurs les velléités de portabilité du code, celui-ci étant de plus en plus développé sur des plate-forme différentes de celles de la mise en production. Aujourd'hui (2001), cela concerne essentiellement des langages comme le C standard et le java.

Compromis d'architecture
    Tout développement applicatif est confronté à classer les propriétés non-fonctionnelles attendues par ordre d'importance.
Par exemple :
- Cohérence vs performance : la gestion de la cohérence de l'information est un élément essentiel dans la conception d'une application d'envergure : il existe de nombreux niveaux de cohérence possibles qui ont chacun leurs coûts associés. Il est fondamental de bien préciser le niveau requis et le prix que l'on est prêt à payer en performance. De cette spécification découleront les choix subséquents de technologie (par exemple, la tolérance aux défaillance matérielle ou logicielle, la présence ou l'absence des transactions, etc...) ;
- Sécurité vs coût : un niveau de sécurité élevé nécessite des investissement (framework d'authentification unique, annuaires, mécanismes matériels d'authentification, mécanismes de cryptage, ...) ainsi que des coûts d'exploitation non négligeables ;
- Sécurité vs ouverture : un niveau de sécurité élevé a une contrepartie évidente en terme de possibilités d'ouverture du système. Inversement, certains choix renforçant l'ouverture du système peuvent diminuer le niveau de sécurité ;
- Qualité de service vs coûts : les performances ont un impact évident en terme financiers : infrastructure réseau, machines (terminaux et serveurs) performants, mécanismes d'équilibrage de charge, ... ;
- etc.