AILES : Architecture, caractéristiques de base

Composants et Éléments
Le schéma suivant détaille la notion de composant introduite parmi les propriétés de base de l'architecture.

    (ce diagramme est intégré dans la modélisation de l'Architecture)
    Composant : les composants d'une architecture sont :
- des données ("DataComponent"),
- des éléments qui transforment ces données ("ProcessingComponent"),
- des éléments qui assurent une connexion entre eux ("ConnectionComponent"). On remarquera que la caractéristique de base Connection utilise un composant de ce type.
Cf. aussi - dans le Questionnaire Langage - les réponses concernant la notion de Composant.
    Sur la partie gauche du diagramme objet ci-dessus, on introduit une notion qui fait partie du framework d'architecture introduit par [SAPF2000], l'Élément ("Element").
    Le lien entre les 2 ?
    Un composant est composé de plusieurs élément, il (le composant) peut exister simultanément sous forme de :
- code (scripts ou codes source),
- exécutables,
- processus.
    Un exemple ? L'ORB (Object Request Broker, permet de distribuer des objets entre différents composants logiciels, que ce soit en distribution locale ou distante, par réseau) est un composant important d'une architecture. Si on prend le point de vue d'un système logiciel qui utilise entre autres un ORB, ce dernier est un composant de connexion ("ConnectionComponent").
Or, un ORB existe simultanément sous forme :
- de code (comme les idl qui sont à la base des stubs et skeleton, codeur et décodeurs d'un objet)
- d'exécutable (comme le serveur de nom qui tourne en permanence),
- de processus (comme l'acheminement d'un objet qui passe par son marshalling, soit sa mise à plat en tableau de bytes, son acheminement via le réseau, et enfin son un-marshalling, soit sa reconstruction).
    Il existe bien d'autres éléments d'architecture, notamment les cas d'utilisation qui permettent la rédaction de scénarios. Ou encore, les acteurs, qui aident à définir la frontière du système étudié. (Tout acteur attend un service ou rend un service au système, mais n'en fait pas parti). En fait, tout ce qui participe à la définition d'un composant d'architecture est un élément, avec son domaine associé.
    La notion de Domaine d'Élément ("ElementDomain") regroupe l'ensemble des sujets traités par un ensemble d'éléments. Quels sujets ? Ceux issus des grandes problématiques que doit traiter une architecture. Ce sont des "sujets" généraux ("Concern") et cette notion est détaillée dans le paragraphe suivant.

Sujets architecturaux et exigences
    Les exigences font parties des propriétés de base déjà présentées. Le schéma suivant fait le lien entre les exigences et la notion plus générale (et comprise dans le framework) de sujets architecturaux ("Concern").

    (ce diagramme est intégré dans la modélisation de l'Architecture)
    Dès que l'on aborde l'architecture, on se préoccupe de sujets architecturaux généraux, comme la sécurité, les temps de réponse, l'évolutivité... mais aussi une division efficace du travail, la conformité à des standards (de qualité), le contrôle de la propagation des changements et des évolutions. Chacune de ces questions se décline dans un des domaines des éléments architecturaux (d'où le lien "within" entre "Concern" et "ElementDomain").
    Ainsi, la problématique de l'évolutivité se pose différemment suivant que l'on se situe dans le domaine de l'exécutable ou du processus (deux "domaines d'élément architectural").
* Si l'on reprend l'exemple de l'ORB, composant de connexion comprenant plusieurs éléments différents, on se rend compte que c'est un composant très structurant en terme de processus (car il implique que les deux composants reliés par cet ORB sachent manipuler des objets et non de simples structures de données). Si un des deux composants reliés par cet ORB change (par un système COBOL par exemple)... le choix de l'ORB est à revoir. (c'était l'exemple déjà présenté dans les enjeux de l'architecture)
* En revanche, si l'on considère le domaine du code, l'option ORB ne pose pas de problème d'évolutivité, tous les ORB du marché étant censés interpréter de la même façon les IDL qui représentent les objets à distribuer.
    Si l'architecture répond, de manière générale et dans le cadre de ce framework, à des "Concerns" (Sujets architecturaux) et ce, dans un ou plusieurs domaines d'éléments architecturaux, seule l'architecture "prescriptive" (qui intervient avant l'analyse du projet) répond aux exigences spécifiques du système informatique commandée par le client.
    Donc, pour résumer et illustrer ce qui précède, si le client impose un univers distribué "tout objet", on peut envisager le choix de la solution "ORB" sans mettre en péril l'enjeu architectural d'évolutivité. Seuls des exigences plus spécifique (en terme par exemple, d'exigences non-fonctionnelles comme un temps de réponse précis) peuvent déboucher sur un choix particulier d'un ORB du marché parmi ceux existant.
    On notera dans cet exemple que le "temps de réponse" est, lorsqu'il n'est pas chiffré, un "enjeu architectural" : l'ensemble des ORB définissent une plage de temps de réponse possibles. En revanche, dès que le client chiffre ce temps de réponse, cela devient une exigence (ici, non-fonctionnelle) qui valide ou non le choix initial (ORB) et guide une sélection.
    Il existe d'autres enjeux architecturaux qui ne se confondent pas avec des exigences clients : une division efficace du travail (déjà mentionné plus haut), ou encore la réutilisation de produits du marché en sont deux exemples : pour le client, peu lui importe la façon dont vous répartissez et parallélisez vos tâches, pourvu que vous rendiez un système opérationnel dans les temps ! Mais pour vous, architecte, ces deux "enjeux" auront un impact sur la façon dont vous aller architecturer votre système...
    Enfin, vous trouverez une illustration concrète de 2 sujets architecturaux (persistance et distribution) dans un exemple de guide d'architecture.

Sphère architecturale
    Les enjeux architecturaux peuvent trouver une autre origine.
    En effet, comme le rappelle le diagramme suivant, un système (qui est ce que vous commande le client) peut comprendre plusieurs architectures. Mais il existe également plusieurs classes de systèmes, organisées en hiérarchie.

    (ce diagramme est intégré dans la modélisation de l'Architecture)
    Chaque niveau constitue une sphère d'architecture, chaque sphère définit le "champ d'application" de l'architecture. Or, si l'on se reporte à la définition de l'architecture, on notera que celle-ci doit "structurer" (organiser) des composants, sans que l'on précise à quoi ces composants se rapportent.
     La sphère est là pour mieux identifier la "classe générale" de ces composants. Cette classe peut être de nature "globale" (composant métier, fonctionnel, technique, ...) ou plus spécifique (composant de déploiement, qui sera d'ailleurs modélisé par un nœud de type, par exemple, "poste de travail").
    L'article sur Les 4 grandes sphères architecturales vous présentent la hiérarchie de sphères couramment rencontrées : métier - fonctionnel - applicatif et technique.
    On associe également à un système des enjeux ("Concern") qui se déduisent de la sphère architecturale à laquelle appartient son architecture. Par exemple, on peut associer à la sphère de déploiement les exigences de montée en charge (car il y a de plus en plus de client) ou d'évolutivité (car il faut pouvoir changer une partie de l'architecture sans remettre en cause les autres déployées à d'autres niveaux).
    Une des classes de système les plus connue est celle d'une architecture en niveau (c.à.d., niveau de déploiement) avec :
- le système central,
- les systèmes départementaux (avec leurs problématiques client-serveur),
- les systèmes distants (avec leur problématique intranet).
(on trouvera un autre exemple de niveau - front office et back office - dans l'article sur le passage entre l'AT et l'AF).
    Vous retrouverez différents exemples de sphère architecturale détaillés dans l'article sur les 4 grandes sphères architecturales.

Composants, Structures et Vue : de l'utilité d'un guide
    La vue architecturale (ou "point de vue")est une notion bien connue des développeurs qui utilisent UML. En effet, cette méthode (UML) préconise une architecture de type "4+1" vue, avec les vues :
- logique (celle comprenant le diagramme statique d'objet),
- dynamique (avec les diagrammes de collaboration et de séquence),
- physique (avec les composants qui représentent du code ou des exécutables, des librairies, des dll, conformément à la définition des composants donnée ci-dessus),
- déploiement (avec le diagramme du même nom, comme celui utilisé dans l'article sur la définition de l'architecture).
- + la vue des cas d'utilisations (Use case et scénarios).
Ce modèle avait initialement été présenté par Philippe KRUCHTEN de Rational en 1995 et publié par IEEE Software, après avoir été discuté de façon informelle depuis 1990.
    Cela ne doit pas faire oublier que l'on peut décider d'un autre ensemble de vue architecturale. Également en 1995, SONI, NORD et HOFMEISTER proposaient les vues :
- conceptuelle, avec les principaux composants,
- d'interconnexion des modules, avec une décomposition en couche et une mise en évidence des interfaces entre modules (cluster de composant),
- dynamique,
- du code (qui regroupe les vues physiques et de déploiement évoquées ci-dessus).
    Enfin, [UMLAction] va plus loin en introduisant pas moins de 8 points de vues : celui des spécification fonctionnelles, le point de vue structurel, matériel, de déploiement, d'exploitation, de spécification logiciel, le point de vue logique et celui de configuration logicielle.
    Attention, on ne confondra pas "point de vue" et diagramme UML. Rien que le point de vue dynamique, 2 diagrammes UML sont nécessaires (séquence et collaboration).
    Enfin, n'oublions pas l'article "Les architectures, les points de vue" qui introduit pas moins de 8 points de vue, 4 fonctionnels, 4 techniques.

    Bref, c'est quoi une vue ?
    Il s'agit de la modélisation d'une ou plusieurs structure. (typique d'une démarche systémique)
    Et c'est quoi, une structure ?
    C'est le regroupement (la partition) d'éléments au sein d'un même domaine d'élément.

    (ce diagramme est intégré dans la modélisation de l'Architecture)
    On remarque qu'une structure regroupe des éléments d'un même domaine. En revanche, une vue peut contenir des structures de domaines différents.
    Concrètement ? Par exemple, considérez la vue "Cas d'utilisation". Elle regroupe deux structures (partition d'éléments) de 2 domaines différents : les cas d'utilisation et les acteurs.
La vue de déploiement peut faire intervenir des acteurs et des nœuds de type "Process". La vue physique emploie deux structures : code et exécutable. Le point de vue dynamique modélise les structures "objets" et "messages" (2 domaines différents), et ce dans 2 diagrammes UML, celui de séquence et celui de collaboration.
Encore une fois, l'élément "ORB" peut se représenter de différentes façons dans ces différentes vues (ou points de vue) en utilisant différentes structures (process avec le marshalling et le un-marshalling, code avec les IDL des objets distants, ... autant de structures, donc de partitions d'éléments chacune dans un domaine différent).
    Et alors, pourquoi s'intéresser tant aux "structures" ?
    Parce que souvent, on essaie à tort d'imposer une structure à différents domaines. Un exemple ?

Une structure de domaine "Process" peut être envisagé pour un système dont les exigences client concernent le parallélisme, la disponibilité et la fiabilité et le temps réel.
En conséquence, on pourrait envisager de représenter le système comme un ensemble de processus parallèles (éléments de même domaine, donc cet ensemble est une "structure").
Si l'on garde la même structure pour définir de nouvelles fonctionnalités qui ne sont pas "temps réel" (donc dont les temps d'exécution ne sont pas garantis), cela veut dire que celles-ci doivent exister sous forme de process "non temps réels" indépendant. Cela implique la définition d'interface afin que les autres process puissent dialoguer avec eux. => Les modules qui en résultent sont plus complexes, leur performance en temps de réponse sont compromises. Mieux aurait valu envisager l'utilisation d'autres structures (donc d'autres domaine que celui des process) pour intégrer ces nouvelles fonctionnalités, et limiter au maximum leurs interactions avec les process ("temps-réel"). Par exemple, ces nouvelles fonctionnalités auraient pu prendre la forme d'exécutable à part, déclenché par les process temps réel par un middleware asynchrone à base de message (mécanisme non "temps-réel").

    Plus généralement, il importe de partir des enjeux architecturaux, de définir les structures qui seront utilisées et de décrire leur utilisation et combinaison. C'est un rôle majeur du guide présenté dans l'article sur la définition de l'architecture et illustré dans cet exemple).
    Les Textures sont des "micro-structures", donc des éléments que l'on retrouve de façon répétée ou récurrente à différentes endroits de l'architecture d'un système.

Vues architecturales
    Attention, il ne faut pas confondre une vue et une structure. Cette dernière est un composant composés d'éléments concrets (comme du code, des process, etc). Une Vue est nécessairement une abstraction. Différentes vues peuvent être des abstraction d'un même composant. Si l'on considère toujours l'exemple de l'ORB (élément déjà utilisé précédemment pour illustrer qu'une vue peut contenir des structures de domaines différents), le process lié à cet ORB (marshalling, transport des données via le réseau, un-marshalling : structure "process" composé de plusieurs éléments "process") pourrait se modéliser aussi bien par une vue dynamique (par un diagramme de séquence ou de collaboration, par exemple), que par une vue de déploiement (donc 2 points de vues différents).
    Les vues architecturales jouent un rôle similaire vis-à-vis des informations d'architecture que les MCD (Modèles Conceptuels de Données) vis-à-vis des bases de données. Elles permettent :
- maintenance, en assurance une cohérence entre la modélisation et la donnée (information d'architecture),
- évolutivité, en permettant l'intégration de nouvelles informations par le biais de nouvelles modélisation.
    Les concepteurs-programmeurs connaissent une illustration concrète de ce qui précède au travers de la modélisation des objets, via la vue logique (et son diagramme de classe). Cette vue est d'ailleurs (souvent de façon automatisée) en cohérence avec la vue physique (qui modélise les structure de domaine "code"). Ce sont ces 2 vues qui permettent une génération de code qui sera à son tour en cohérence avec la modélisation (ce qui est un des enjeux majeurs des AGL).
De plus, l'ajout de nouveaux code se fait via l'ajout de nouvelles classe (éléments du diagramme de classe de la vue logique) et l'ajout de nouveaux éléments "code" (dans la vue physique).
Comme annoncé... maintenance et évolutivité... le tout en passant systématiquement par les vues d'architectures (et non plus directement par le code).
    Enfin, n'oublions pas que cette notion de "point de vue" est fondamentale pour définir le contenu d'une architecture (car elle participe au processus d'abstraction du système, en permet sa modélisation et, au final, son implémentation).
Prasad YALAMANCHI (Director, Sofware Development, Orillon USA, Houson TEXAS) le souligne ainsi :
« Architecture exists whenever parts relate to each other and the resulting whole. An architecture exists everywhere there is a whole made from parts because they make the whole in one possible way. ONLY points of views make architectures desirable or less desirable. »