Architecture :
exemple de guide d'architecture
[Architecture],
[SEI], [SAPF2000]

Pour faciliter la mise en oeuvre d'un sujet architectural comme la persistance, un architecte devrait fournir aux concepteurs / développeurs un template (ou un patron, ou un... heu, "guide", justement).     Dans le schéma qui suit, la classe importante que connaît le concepteur est  PersistentClass, la classe qui doit être persistante, qui plus est dans une base de données relationnelle via JDBC...       Ce schéma indique alors que, pour chaque classe persistante, l'architecte suggère de : - doter cette classe persistante ("PersistentClass") d'un mécanisme de type "map" (clé, valeur)  permettant d'extraire ou de remplir les attributs de la classe persistante (ce mécanisme vient s'ajouter en plus des méthodes pré-existantes de cette classe) ; - créer une classe médiateur entre le monde OO (orienté objet) et le monde BDR (base de données relationnelle) : "DBClass" (donc, pour une classe persistante "Facture", on aurait un médiateur "DBFacture") ;     Le principe ? Pour passer d'un monde objet à un monde de structures relationnelles, il faut "aplatir" les objets et reconstituer leurs relations. La "DBClass" est utilisée à chaque fois qu'une classe persistante doit être créée, accédées ou détruite.     Par exemple, pour lire un objet persistant, on consultera le diagramme de séquence suivant :     On peut y voir qu'une fois la requête SQL exécutée, chaque attribut d'une classe persistante est lu, puis inséré dans la classe persistante.

    Même si ce mécanisme aurait besoin d'être encore plus détaillé, et même si bien des schémas manquent à ce guide (en particulier ceux de création, mise à jour ou destruction d'un objet persistant), vous devez commencer à voir que le travail d'un architecte ne consiste pas seulement à jeter quelques choix technologiques (JDBC, RMI, ...) sur un diagramme de déploiement (comme celui qui illustrait l'article sur la l'architecture descriptive).
    Le deuxième exemple qui suit est du même acabit. Vous pouvez également vous rendre en fin d'article pour bien saisir l'importance de ce travail de guide d'un architecte.

Deuxième sujet d'architecture : la distribution des objets
    Rentrer dans l'univers des objets distribués n'est déjà pas facile en soi (en particulier parce qu'il faut bien déterminer quoi distribuer, afin d'éviter de se retrouver avec des giga-octets d'objets qui se baladent sur le réseau, et en écroule les performances - du-dit réseau -).
    Ce qui suit peut aider à sa mise en oeuvre technique.

Pour distribuer des objets en RMI, un certain nombre de classes doivent être définies. Le schéma suivant aide à visualiser lesquelles.     Ainsi, pour une classe identifiée comme devant être "distribuable" (ici "SampleDistributedClass"), l'architecte suggère : - l'utilisation du mécanisme de "Naming", afin d'obtenir une référence sur des objets distants, référence de type "rmi://host:port/name") ; - la création d'une interface de type "Remote" correspondante  ("ISampleDistributedClassInterface") qui déclare toutes les méthodes que l'on souhaitera voir accessible de façon distante (comme "doSomething") ; - la sérialisation de tout paramètre ("SamplePassedData") ;     L'appel à une méthode ("doSomething") d'un objet distant s'illustre ainsi :     La mise en oeuvre du mécanisme de distribution peut se faire facilement à partir des classes que l'on aura identifiée comme devant permettre d'offrir des services distants. Il suffit : - de créer les classes présentées dans le premier diagramme ; - de suivre l'ordre d'appel du deuxième diagramme.

Conclusion
    Qu'à fait l'architecte en proposant ce guide sur ces deux sujets architecturaux ?
- il permet aux concepteurs et développeurs de se concentrer sur l'identification des classes (persistantes et distribuées) issues de l'analyse ;
- il facilite la mise en oeuvre technique de ces sujets ;
- il peut même offrir des scripts qui automatiseront l'ajout des classes et/ou des méthodes nécessaires pour passer de l'analyse (où une classe est stéréotypée comme devant être distribuée) à la en conception (où la même classe comporte les méthodes supplémentaires qui lui manquaient, ainsi que les relations vers les classes techniques nécessaires).

    Encore une fois, un guide d'architecture comporte bien des étapes avant et après ces exemples de sujets architecturaux. Mais cette partie illustre bien une des définitions de l'architecture issues du [SEI] :

Adu MATTHAEUS (System Architect, Eikon, Centurion South Africa) :
« Software Architecure ? a configurable skeleton of any kind of software beast on which you hang implementation specific muscle to make it live ! »
(et les "muscles spécifiques d'implémentation" étaient ici JDBC et RMI!)

Enfin, Philippe KRUCHTEN, déjà mentionné pour son modèle d'architecture à 4 + 1 vues, a revisité quelques citations de Lao-Tsu, les Tao Te Ching (cf. [SEI], partie "Essays"), et cela donne (toujours pour illustrer cette notion de guide) :

« The architect doesn't talk, he acts. When this is done, the team says : "Amazing : we dit it, all by ourselves !" »

« When the process is lost, there is good practice. When good practice is lost, there are rules. When rules are lost, the is Ritual...
Ritual is the beginning of chaos. »
Philippe KRUCHTEN commente cette dernière "citation" comme étant proche de Jim ARCHER (SEI CMM), qui disait :

« First, you pay for result, then you pay for effort, finally, you pay for attendance. »