Donner une définition claire de l'architecture logiciel est chose parfois peu aisée car le sujet englobe une grande partie du processus de développement.
Dans ce billet, pour clarifier les choses, je vais considérer que l'architecture englobe :
- le design
- l'interaction des composants (organisation des composants)
- l'infrastructure (l'hébergement des composants)
Ces différents éléments qui sont, en réalité, des vues sur le système informatique peuvent se résumer au diagramme suivant:
Ce diagramme nous indique comment percevoir notre système informatique (le système informatique se compose en général d'un logiciel et d'une plateforme physique ou logique permettant de le faire fonctionner).
La vue la plus importante, celle qui dirige et qui induit le système, est la vue de cas d'utilisation.
Les cas d'utilisation représentent les fonctionalités que le système va offrir aux utilisateurs. A chaque cas d'utilisation correspondent différents scénarios : un scénario principal décrivant la fonctionalité attendue, des scénarios alternatifs prenant place lorsqu'une erreur se produit ou qu'une donnée est manquante.
Les quatre vues suivantes ne font qu'implémenter concrètement les spécifications qui ont été définies dans la vue de cas d'utilisation.
La vue logique décrit comment sera organisé le code, comment seront regroupées les fonctions qui réaliseront les cas d'utilisation. Ces fonctions appartiendront à des classes qui pourront collaborer entre elles en vue des réaliser les cas d'utilisation définis. Cette vue est parfois la seule visible pour des petits systèmes d'information.
La vue de processus décrit comment vont fonctionner et comment seront synchroniser les threads ou les processus réalisant des opérations en parallèle. Si le logiciel utilise des services, il génère des threads chaque fois qu'il doit gérer de nouvelles connections, ...
La vue de réalisation (collaboration) décrit comment les composants interagiront ensemble et où ils seront stockés. Ceci peut être représenté par un diagramme de composants. Les noeuds qui contiennent ces composants seront également décris. Cette vue est très utile dans les systèmes distribués.
La vue de déploiement décrit comment le système informatique sera organisé, déployé. Cette vue peut ressembler au diagramme de composant sauf que, ici, l'accent sera mis sur l'agencement du réseau et des serveurs (noeuds).
Les gros systèmes seront généralement décrits par ces quatre vues, les plus petits systèmes se contenteront généralement de la vue logique.
Les types d'architectures logiciels:Les types d'architecture vont indiquer comment les composants d'un logiciel vont se répartir. On distingue en général des composant utiles à l'affichage, au traitement et au stockage. Une architecture relativement courante dans les systèmes d"information est l'architecture dite
Client/Serveur.Un logiciel client installé sur un poste de travail accède aux données stockées sur un serveur de base de données. Cette architecture permet de partager facilement des informations entre différents utilisateurs répartis sur des postes différents. En général, cette architecture se limite au réseau physique de l'entreprise. Si les postes de travail sont relativement évolués, les programmes clients pourront aussi effectuer des traitements locaux sur les données. Ceci permet de répartir la charge de travail entre le serveur et les clients.
L'architecture 3 ThiersCette architecture est souvent utilisée par les applications Internet (application de eCommerce, de data-capture, ...). Dans ce type d'application, le client est un browser Internet qui permet des traitements relativements légers. Le client accède à un web-serveur qui lui renvoie des pages HTML (HyperText Markup Language) générées dynamiquement. Cette génération dynamique se fait en général par des extensions du web-serveur. Il peut s'agir de DLL, DSO, script CGI(remarquez que PHP par exemple fonctionne sur base d'une DSO).
L'avantage de cette architecture est de s'ouvrir au monde. En effet, il sera possible d'accéder aux données en dehors du réseau local puisque les accès se feront à travers Internet. Toutefois, si on laisse les extensions sur le web-serveur, on arrive très vite au problème de montée en charge. Que se passe-t-il si trop d'utilisateurs se connectent sur le serveur et que le CPU ou la mémoire s'effondre ? Le système deviendra inutilisable. Nous arrivons donc à un problème crucial qui est la "scalabilité" (déjà évoqué dans un précédent billet) c'est-à-dire la faculté de pouvoir fonctionner quel que soit le nombre d'utilisateurs connectés en même temps.
Les architectures distribuées.Les architectures distribuées utilisent des composants (EJB, COM, COM+, assembly .Net, ...) pouvant s'éxécuter sur un serveur d'application. Ces composants seront sollicités par les extensions du web-serveur. L'avantage de cette approche est que certains composants pourront fonctionner sur un serveur d'application alors que d'autres fonctionneront sur un autre. Ceci permet de répartir la charge et ceci a pu voir le jour grâce à des technologies comme CORBA ou DCOM qui permettait d'invoquer des méthodes de composants à travers le réseau.
Par la suite, DCOM a été remplacé par COM+ qui a lui même évolué en .Net.
D'une manière générale, l'invocation des composants et l'organisation de ceux-ci se fait sur un même réseau local.
Les architectures de services.
L'architecture de service qui a vu le jour dans le début des années 2000 outrepasse la capacité d'utiliser des composants organisés sur un réseau local mais permet d'utiliser des services n'importe où sur Internet.
Un exemple simple serait la possibilité pour le système informatique d'une agence de voyage de communiquer avec le système de réservation d'une compagnie aérienne. Les deux infrastructures sont totalements séparées mais, grâce à l'architecture de service, il serait possible à l'agence de voyage de réaliser automatiquement la réservation du billet d'avion. Cela peut se réaliser au moyen des Web-Services qui sont des composants distribués à travers l'Internet.
