Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage, je m'appelle Nicolas
Brondin-Bernard et aujourd'hui on va parler de ce qui est l'architecture logicielle.
Alors dans les métiers de la construction, l'architect c'est celui ou celle qui conçoit
en amont les plans nécessaires, on va dire à la fabrication d'un bâtiment.
L'objectif c'est de partir des besoins spécifiques du client pour arriver à un plan détaillé
des solutions possibles tout en utilisant son expertise métier.
Et bien c'est exactement la même chose pour l'architecture logicielle.
Un architecte ou une architecte logicielle va prendre en compte les besoins et le contrainte
du client mais également les contraintes du projet spécifiquement pour proposer la
modélisation d'une solution technique qui correspondra au mieux au projet de départ.
Alors c'est normal on peut se dire de prévoir ces changements là puisque dans l'architecture
classique on ne va pas prévoir un projet d'appartement, un projet d'immeuble, un
projet de maison ou un projet d'opéra de la même manière.
Évidemment, c'est pareil en fonction des contraintes on va devoir faire des choix
et il va y avoir des contraintes.
Mais par contre il y a une grosse différence entre l'architecture classique et l'architecture
logicielle c'est la fréquence des changements parce que quand on construit un bâtiment
évidemment ce bâtiment il doit être fonctionnel et robuste mais un logiciel lui il sera en
constante évolution.
C'est donc le travail de l'architecte et évidemment des développeurs et des développeuses
ensuite de faire en sorte que la solution technique soit fonctionnelle, robuste et évolutive.
Alors pour arriver à concevoir une architecture il faut bien comprendre les enjeux du projet
mais aussi avoir une très bonne connaissance des contraintes techniques qui peuvent impacter
le fonctionnement du projet.
Alors même si l'architecte n'est pas censé implémenter directement la solution,
Hillwell doit préparer les spécifications du projet le mieux possible pour que l'implémentation
se fasse avec le moins de problèmes.
Alors est-ce qu'on a des outils spécifiques ? L'architecture logicielle ne s'arpose pas
sur des plans à proprement parler mais plutôt sur des langages de modélisation qui eux-mêmes
comprennent des outils normalisés souvent des diagrammes pour concevoir justement cette
architecture.
Alors le langage le plus utilisé en architecture logicielle il s'appelle l'UML et il signifie
Unified Modeling Language.
Alors en UML on retrouve une dizaine de types de diagrammes différents avec chacun leur
représentation et leur utilité.
On a par exemple des diagrammes de cas d'utilisation pour représenter l'interaction des utilisateurs
avec le logiciel.
On a des diagrammes d'activité pour modéliser un comportement logique si jamais il se passe
ça alors il se passe ça c'est comme des conditions logiques.
On a des diagrammes de classe pour la structure des données métiers.
On a des diagrammes de séquence là pour modéliser l'échange d'informations ou de données.
Et il y en a encore évidemment bien d'autres.
Si jamais vous voulez voir à quoi ressemblent certains des diagrammes les plus utilisés
je vous invite à aller voir dans les notes de l'épisode.
Je vous ai mis l'article d'origine de cet épisode de podcast et dedans vous avez des
exemples graphiques avec des diagrammes.
Alors une fois que le travail d'architecture logicielle est terminé on peut démarrer l'implémentation
mais par contre une phase d'architecture est souvent requise à chaque grosse évolution
du projet.
La dernière chose c'est qu'il ne faut pas confondre architecture logicielle avec architecture
des systèmes d'information.
L'architecture des systèmes d'information ça consiste plutôt à concevoir planifier
les serveurs, leurs disponibilités, le réseau et toute l'infrastructure d'un projet
enfin autour d'un projet ou d'une entreprise.
L'architecture logicielle va vraiment se concentrer sur les données, les interactions,
les utilisateurs et la logique.
Voilà et pas du tout sur l'infrastructure mais c'est pour ça qu'on a besoin de tous
ces métiers là et qu'il travaille main dans la main pour faire fonctionner un projet
au mieux.
J'espère que cet épisode vous aura été utile.
Moi je vous donne rendez-vous la semaine prochaine pour un prochain épisode et si jamais
vous écoutez cet épisode sur Apple Podcast n'hésitez pas à laisser cinq étoiles et
avec en commentaire un sujet que vous aimeriez que j'aborde dans un de ces épisodes.
Mais je vous donne aussi et surtout rendez-vous sur notre plateforme code-garage.fr pour retrouver
tous les cours, les articles de blog, les podcasts aussi et énormément d'autres ressources
pour continuer à vous former, faire votre veille et tout ce dont vous avez besoin en
tant que développeur ou développeuse.
A la semaine prochaine, salut !