L’architecture logicielle

Mon parcours dans l’industrie de l’ingénierie logicielle m’a permis d’appréhender de nombreux éléments nécessaires à la réussite d’un projet de développement logiciel. L’architecture logicielle est l’un de ces éléments, j’aborderai avec vous tout au long de cet article les différents concepts gravitant autour de l’architecture logicielle.

Qu’est-ce que l’architecture de logiciel ?

De nombreux développeurs ont du mal à définir l’architecture logicielle et il existe de nombreuses définitions différentes publiées sur Internet. Pour être franc j’avais moi-même du mal à le définir.

Je la définirai comme suit : l’architecture logicielle est le processus de définition d’un plan qui décrit un ensemble d’aspect et de décisions important pour un logiciel. Cela demande une prise en compte d’exigences (performance, la sécurité, la disponibilité, etc.), la manière dont les parties du système communiquent et bien plus encore.

Martin Fowler : “The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system’s lifetime; and, in the end, architecture boils down to whatever the important stuff is.”

L’architecture logicielle possède des caractéristiques permettant de la définir au mieux.

La séparation des responsabilités (Separation of concerns)

La séparation des responsabilités est la caractéristique de l’architecture logicielle qui décrit l’isolation des responsabilités du logiciel en section distincte. Cela signifie que chaque section isolée apporte une solution à un problème ou un ensemble de problèmes communs. Cette caractéristique offre un degré de liberté pour la conception, pour le déploiement et pour l’utilisation/réutilisation. Un logiciel qui incarne bien cette caractéristique peut être appelé logiciel modulaire.

Orienté vers la qualité (Quality-Driven)

La qualité d’une architecture logicielle est un aspect très important, le logicielle doit être axée sur la qualité pour être efficace dans l’exécution de ses fonctions essentielles.

Voici une liste non exhaustive des attributs de qualité courants que votre architecture logicielle doit prendre en considération :

La performance : La performance est la vitesse des choses, généralement en matière de temps de réponse ou de latence.

Temps de réponse : Le temps qui s’écoule entre l’envoi d’une demande et la réception d’une réponse

Latence : Le temps qu’il faut pour qu’un message ou un événement traverse votre système d’un point A à un point B.

La scalabilité : La scalabilité est essentiellement la capacité de votre logiciel à gérer un plus grand nombre de flux d’informations.

La disponibilité : La disponibilité est la mesure dans laquelle votre logiciel est opérationnel et, par exemple, disponible pour répondre aux demandes.

La sécurité : La sécurité couvre les concepts d’authentification et d’autorisation jusqu’à la confidentialité des données en transit et en stockage.

Le monitoring : Le monitoring vous permet de surveiller, analyser, contrôler l’état de votre logiciel.

Les styles récurrents

L’architecture logicielle a des méthodes standard pour résoudre les problèmes récurrents, tout comme l’architecture des bâtiments. Il existe également des termes connexes pour les styles récurrents, tels que les principes architecturaux, les tactiques et les patterns.

L’intégrité conceptuelle

Le terme d’intégrité conceptuelle a été introduit par Fred Brooks à travers son célèbre livre “The Mythical Man-Month”. Elle désigne l’idée que l’architecture d’un système logiciel représente une vision globale de ce qu’il doit faire et de la manière dont il doit le faire. Nous pouvons donc considérer que l’architecte logiciel assume les responsabilités de la “superviser la vision” et de la “manière dont elle est mise en œuvre”.

La considération de la multitude de parties prenantes

L’une des principales caractéristiques de l’architecture logicielle est qu’elle doit répondre aux besoins d’une multitude de parties prenantes. Ces parties prenantes ont toutes leurs propres préoccupations en ce qui concerne le système. Équilibrer ces préoccupations et démontrer qu’elles sont prises en compte fait partie de la conception du système. Cela signifie que l’architecture implique de répondre à un large éventail de préoccupations et de parties prenantes, et est de nature multidisciplinaire.

Pourquoi l’architecture logicielle est-elle essentielle à la réussite des projets de développement logiciel ?

Il est important de savoir que pour réussir un projet de développement logiciel il ne suffit pas simplement d’écrire du bon code. Si aucun membre de votre équipe ne pense à l’architecture logicielle, vous obtenez souvent une base de code non sécurisée, fragile, instable, difficile à déployer, difficile à maintenir, difficile à modifier, difficile à étendre, etc. J’ai vu et travaillé sur des bases de code qui rencontrent ces difficultés et je peux vous dire que c’est très insatisfaisant de travailler dans de telles conditions.

En outre, en l’absence d’une direction technique, de nombreuses bases de code finissent par ressembler aux stéréotypes de la “grosse boule de boue” ou du “code spaghetti”. Ces projets logiciels apparemment désordonnés,décousus existent dans le monde réel et tournent en production chez de nombreuses entreprises et une majorité de développeurs travaille sur ce genre de projet.

L’importance de l’architecture logicielle devient donc évidente afin d’éviter la naissance d’un projet logiciel chaotique.

Les bénéfices d’avoir une architecture logicielle cohérente

Vous pouvez obtenir de nombreux avantages en ayant une excellente architecture logicielle. Voici quelques-uns des avantages auxquels vous pouvez vous attendre.

Une vision commune

Une vision et une feuille de route claire que l’équipe doit suivre, que cette vision soit détenue par une seule personne ou collectivement par l’ensemble de l’équipe.

Une réduction du coût du développement du logiciel

Une architecture logicielle correctement établie permet la réduction du coût global d’exploitation d’un système logiciel. En effet, elle permet d’éviter certains problèmes qui peuvent vous faire dépenser davantage sur le projet logiciel. En outre, vous bénéficiez également des avantages financiers liés à une meilleure efficacité de votre logiciel.

Une meilleure maintenabilité de la base de code

Une maintenance plus douce moins contraignante devient évidente avec une architecture logicielle solide.

Une base solide

Une bonne architecture logicielle vous aide à créer un ensemble de fondations solides pour le produit en cours de construction. Cela signifie qu’il devient facile de rendre votre logiciel évolutif.

Est-il obligatoire qu’un projet logiciel ait besoin d’une architecture logicielle ?

Pour être franc, il m’est difficile de donner une réponse exacte à cette question. Si je m’efforce à répondre je donnerai la réponse suivante :

ça dépend

En réalité tout dépend de la nature, de la taille du projet et aussi de la considération qu’on lui apporte. Une équipe ou un développeur ne sera pas obligée de considérer l’architecture logicielle d’un projet de type PoC (proof of concept).

Pour ma part chaque équipe doit analyser un certain nombre de facteurs afin d’évaluer le degré de réflexion nécessaire en matière d’architecture logicielle, dont un certain degré se manifeste sous forme de conception initiale. Il s’agit notamment de la taille du projet, de la complexité du projet, de la taille de l’équipe et de l’expérience de l’équipe.

Dave Thomas : “Big design up front is dumb. Doing no design up front is even dumber.”

Les principes

Les principes sont les règles que vous souhaitez soumettre afin d’introduire des approches communes et cohérentes dans la manière dont vous construisez un logiciel. Nous avons un certain nombre de principes communs, certains liés au développement et d’autres à l’architecture.

Les principes de développement

Les principes de développement concernent les règles qui décrivent la manière dont votre logiciel doit être développé. Nous pouvons noter les principes suivants :

Les normes et conventions de codage : Elles décrivent un ensemble de règles à suivre pour uniformiser les pratiques de développement logiciel, diffuser les bonnes pratiques de développement et éviter les erreurs de développement “classiques” au sein d’un groupe de développeurs.

Les outils d’analyse statique de la base de code : Elles doivent être nécessairement intégrées dans vos projets logiciels, elles vous permettront d’analyser la qualité de votre code durant la phase de développement et de l’améliorer en conséquence.

Les tests unitaires et d’intégrations : Les tests unitaires et d’intégrations doivent être obligatoires et ceci ne doit pas être négociable. Elles vous permettront d’avoir un premier niveau de contrôle sur le bon fonctionnement de votre base de code.

La documentation : Ici il s’agit de documenter la base de code qui concerne/représente les règles métiers qui régissent votre logiciel. Elle fournit des informations sur la façon dont le projet fonctionne et pourquoi. Cela accélère considérablement la courbe d’apprentissage des règles métiers d’un nouveau développeur qui rejoint votre équipe, Il pourra à travers le code comprendre le métier sans pour autant aller à la rencontre des experts du métier.

Les principes d’architecture

Les principes d’architecture abordent le sujet de la structuration des composantes du logiciel. Une liste non exhaustive de quelques principes :

La cohésion

D’après Wikipedia la cohésion désigne le degré d’appartenance des éléments d’un module. En outre, nous pouvons dire qu’elle représente la clarté des responsabilités d’un module.

Les modules à forte cohésion ont tendance à être préférables, tout simplement parce qu’une forte cohésion est associée à plusieurs caractéristiques souhaitables du logiciel, notamment la robustesse, la fiabilité et la compréhensibilité.

Une faible cohésion peut générer des problèmes tels que la difficulté à maintenir, tester, réutiliser ou à même comprendre la base de code.

Le couplage

Le couplage est le degré d’interdépendance entre les modules d’un logiciel. Il est primordial d’avoir un couplage lâche/faible.

Le couplage lâche désigne une relation dans laquelle un module interagi avec un autre module par le biais d’une interface simple et stable et ne doit pas se préoccuper de l’implémentation interne de l’autre module.

Un domaine riche et non anémique

Démarrons par l’explication d’un domaine anémique. Un modèle de domaine anémique est un modèle qui ne contient aucune logique. Les classes de domaine ressemblent plus à un tas de setters et getters publics sans logique de domaine où le client de la classe a le contrôle sur la façon d’instancier et de modifier la classe. Dans ces modèles, le client doit interpréter l’objectif et l’utilisation de la classe. Le plus souvent le logique métier est géré par d’autres classes appelées services, helper ou manager en du plus du nom de la classe de domaine.

OrderService, OrderUtil, OrderManager, OrderHelper

Évitez au maximum d’avoir des domaines anémiques car cette approche entraîne de nombreux problèmes et inconvénients de conception, quelques exemples ci-dessous:

• Le viole du principe de l’encapsulation (POO)
• Difficulté à maintenir la base de code
• Duplication du code destiné à résoudre les problèmes du métier
• Impossible de garantir que les entités du modèle sont dans un état cohérent
• Faible cohésion

Un domaine riche va vous permettre d’éviter toutes les difficultés d’un domaine anémique. La principale différence avec un modèle de domaine anémique est que notre logique de domaine fait partie des entités de notre domaine, les données et le comportement étant réunis. Cette logique guide et contrôle la façon dont l’entité est instanciée, validée et exploitée, réduit le risque d’avoir des classes avec un état incohérent.

SOLID

Les principes SOLID sont cinq principes de conception de classes orientées objet. SOLID est un acronyme mnémonique qui regroupe cinq principes de conception destinés à produire des architectures logicielles plus compréhensibles, flexible et maintenable. Les principes SOLID ont été présentés pour la première fois par Robert J. Martin (alias Uncle Bob) dans son article de 2000. Les principes sont les suivants :

• The Single Responsibility Principle : Il ne devrait jamais y avoir plus d’une raison pour qu’une classe change. En d’autres termes, chaque classe ne devrait avoir qu’une seule responsabilité.
• The Open-Closed Principle : Le principe “ouvert-fermé” exige que les classes soient ouvertes à l’extension et fermées à la modification.
• The Liskov Substitution Principle : Le principe de substitution de Liskov stipule que les sous-classes doivent être substituables à leurs classes de base.
• The Interface Segregation Principle : La ségrégation signifie garder les choses séparées et le principe de ségrégation des interfaces consiste à séparer les interfaces.
• The Dependency Inversion Principle : Le principe d’inversion de dépendance stipule que nos classes doivent dépendre d’interfaces ou de classes abstraites plutôt que de classes et de fonctions concrètes.

Style d’architecture — Architectural Styles

Les styles architecturaux nous indiquent dans les grandes lignes la manière dont seront organisés les composants d’un logiciel. Elle détermine une famille d’architecture qui partage certaines caractéristiques. Les styles d’architecture ne nécessitent pas l’utilisation de technologies particulières, mais certaines technologies sont bien adaptées à certains styles architecturaux. Par exemple, les conteneurs sont naturellement adaptés aux microservices.

La compréhension des styles architecturaux présente plusieurs avantages. L’avantage le plus important est qu’ils fournissent un langage commun. Ils offrent également des possibilités de conversations qui sont agnostiques sur le plan technologique.

Quelques exemples de styles d’architecture :

• N-tier

Le modèle d’architecture le plus courant est le modèle d’architecture en couches, également connu sous le nom de modèle d’architecture n-tiers. Les dépendances sont gérées en divisant l’application en couches qui remplissent des fonctions logiques, telles que la présentation, la logique métier et l’accès aux données. Une couche ne peut faire appel qu’aux couches qui se trouvent en dessous d’elle.

• Web-Queue-Worker

Dans ce style, l’application dispose d’un frontal Web qui traite les demandes HTTP/HTTPS et d’un Worker dorsal qui exécute les tâches gourmandes en ressources CPU ou les opérations de longue durée. La partie front communique avec le Worker par le biais d’une file d’attente de messages asynchrones.

• Microservices

Le style d’architecture microservices est composé de nombreux petits services indépendants. Ces services sont construits pour répondre à une fonctionnalité unique ou des fonctionnalités ayant de très fortes affinités et peuvent être déployés de façon indépendante. Les services sont faiblement couplés et communiquent par le biais de contrats API.

• Event-driven architecture

Le style d’architecture événementielle est un modèle d’architecture asynchrone distribuée qui utilise un modèle de publication et d’abonnement (pub-sub), dans lequel les producteurs publient des événements et les consommateurs s’abonnent. Les producteurs sont indépendants des consommateurs, et les consommateurs sont indépendants les uns des autres.

Il est important de savoir qu’un style d’architecture impose des contraintes à la conception, notamment l’ensemble des composants qui peuvent apparaître et les relations autorisées entre ces composants.

Patron d’architecture — Architectural Patterns

Un pattern est une solution récurrente à un problème récurrent. Les patterns d’architectures résolvent les problèmes liés aux styles d’architecture. Les patterns d’architectures impact directement la base de code du projet, que ce soit horizontalement (c’est-à-dire la façon de structurer le code à l’intérieur d’une couche) ou verticalement (c’est-à-dire la façon dont une requête est traitée des couches externes vers les couches internes et inversement).

Quelques exemples de pattern d’architecture :

• Model-View-Controller

MVC (Model-View-Controller ou Modèle-Vue-Contrôleur) est un modèle dans la conception de logiciels. Il met l’accent sur la séparation entre la logique métier et l’affichage du logiciel. Cette séparation des préoccupations permet une meilleure répartition du travail et une maintenance améliorée.

• Model View ViewModel

Le pattern MVVM, communément appelé Model-View-ViewModel, est un modèle de conception de l’interface utilisateur (UI). Le pattern MVVM prend en charge la liaison de données(data binding) bidirectionnelle entre la View et le ViewModel.

• Microkernel

Le modèle d’architecture microkernel se compose de deux types de composants d’architecture. Un système central et des modules complémentaires/extensibles. La logique applicative est répartie entre des modules plugin indépendant et le système central de base, ce qui permet l’extensibilité, la flexibilité et l’isolation des fonctions applicatives et de la logique de traitement personnalisée.

• Hexagonal architecture

L’architecture hexagonale ou architecture à base de ports et d’adaptateurs vise à créer des systèmes à base de composants d’application qui sont faiblement couplés et qui peuvent être facilement connectés au moyen de ports et d’adaptateurs. Ces composants sont modulaires et interchangeables ce qui renforce la cohérence des traitements et facilite l’automatisation des tests.

Un style d’architecture est simplement un nom donné à une conception architecturale récurrente. Un pattern d’architecture est une solution à un problème d’architecture répétitif. Nous pouvons donc avoir une architecture qui mixte plusieurs styles architecturaux et chaque style architectural peut faire appel à plusieurs patterns architecturaux.

Conclusion

Ce que vous devez retenir de cet article c’est l’importance évidente de l’architecture logicielle dans la réussite d’un projet logiciel et de son énorme impact sur les membres de l’équipe durant la phase de développement et pendant la maintenance.

Vous devez garder à l’idée que l’adoption de l’architecture logicielle doit vous apporter une réelle valeur ajoutée à la réalisation de votre projet, sinon l’équipe ne fera que gaspiller du temps précieux et des efforts.

J’ai abordé une partie infime des aspects gravitants autour de l’architecture logicielle et malheureusement je ne peux pas aborder un sujet aussi complexe dans un seul article.

D’autres articles suivront, le prochain sera dédié au rôle de l’architecte logiciel.