Cette série d’articles se concentre sur les notions et concepts de l’architecture logicielle. Vous n’y trouverez donc pas d’éléments techniques.

Avant d’entrer dans le vif du sujet, je tiens à préciser que l’architecture ne doit pas être vue comme une discipline exécutée par quelques personnes spécialisées. Elle doit être intégrée dans le travail de tout développeur.

du “Big Design Up Front” à l’architecture émergente

Dans la pratique de l’architecture logicielle, historiquement l’architecture à été un travail pensé en phase d’avant projet. Cependant, depuis quelques années, les méthodes agiles cherchent à modifier cet ordre des choses et ont mis au point des pratiques d’architectures au fil de l’eau.

C’est pourquoi les pratiques d’architecture avant projet venant des méthodes de projet en V ou en cascade (nommées “Big Design Up Front” — BDUF) et les architectures émergentes (venant des méthodologies agiles : XP, Scrum, etc.) sont opposées dans leur approche. Plus d’information sur les méthodes de gestion de projet informatique sur la fiche wikipedia dédiée.

Big Design Up Front

Cette pratique consiste à penser l’architecture du logiciel avant la phase de développement. Souvent réalisée par des personnes dédiées, l’architecture se retrouve déconnectée de la phase développement.

La phase d’architecture étant en amont, elle nécessite que les besoins fonctionnels soient figés, ce qui est rarement le cas au début du projet. L’adaptation au changement de l’architecture est quasi-nulle cela peut entraîner des problèmes importants en cas de mauvaise conception initiale.

Les erreurs d’appréciation sont fréquentes. C’est la raison pour laquelle, cette pratique a tendance à créer des architectures beaucoup plus complexes que nécessaire. Et la grande quantité de documentations générée par ce type d’architecture peut créer un faux sentiment de contrôle sur la solution alors même que des éléments importants peuvent être oubliés.

De plus, les architectes peuvent finir par être déconnectés du terrain, créant un phénomène de tour d’ivoire accentuant encore les problématiques déjà citées. Pire, un sentiment de dévalorisation peut apparaître auprès des développeurs qui se retrouvent alors en simple position d’exécutant.

Cependant, il ne faudrait pas croire qu’une phase d’architecture en amont de la production logicielle ne soit pas nécessaire. Mais cette phase doit être limitée à la création d’une vision technique pour le produit, sans aller dans les détails de l’implémentation. Nous parlons dans ce cas d’un “just enough” (juste assez) up front design, notion sur laquelle nous reviendrons un prochain article.

Les systèmes complexes sont un type de projet nécessitant une phase d’architecture en amont. Celle-ci sera plus souvent confié à un architecte en système d’information qui découpera le projet en un ensemble inter-connecté de composants simple. Ces différents composants pourront alors être développé selon les pratiques de “l’emergent design”.

Un autre cas particulier est à prendre en compte pour l’utilisation de cette méthodologie : la reprise de système existant. Dans ce cas de figure, une phase d’architecture en amont est indispensable pour cartographier le code source actuel et préparer les futurs développements.

L’architecture émergente (ou “emergent design”)

Les architectures émergentes se construisent tout au long de la phase de développement. Utilisées massivement par les méthodes agiles, c’est une pratique qui offre beaucoup d’avantage à la condition d’une grande rigueur dans sa mise en œuvre (au niveau des tests notamment).

Le principe de ce type d’architecture est assez simple : les développeurs écrivent un module A, puis un module B. À la fin de la création du module B ils vont chercher les éléments communs à A et B et les factoriser au cours d’une phase dite de “refactorisation”. Ce processus est répété tout au long de la création du logiciel. L’architecture va donc apparaître au fur et à mesure de l’avancée du projet.

Dans ce cas, l’architecture est confiée au soin des développeurs, il faudra donc faire attention à avoir une équipe solide techniquement pour limiter les erreurs nuisant à la maintenabilité future du logicielle. Pour éviter ce type de problèmes, une solution est de mettre en place une équipe de coachs inter-projets qui aideront les équipes dans les phases complexes de la création du logiciel.

Attention, pour éviter des régressions importantes lors des nombreuses phases de refactorisation, il est indispensable de tester unitairement le code source. Dans ce cadre, la mise en place de méthodes orientées sur les tests (ex : “test driven developpement”, consistant à écrire les tests avant le code) doivent être généralisée. Un manquement à cette pratique à un effet délétère sur le code source qui devient in-maintenable.

Les avantages apportés par ces pratiques sont nombreux, sans vouloir être exhaustif nous pouvons citer :

  • Le changement est le bienvenue, en effet l’architecture se construit avec le logiciel. Un changement dans le logiciel n’aura donc qu’un impact très limité sur le logiciel.
  • Le code est souvent plus concis, les développeurs ne développant que ce dont ils ont effectivement besoin, sans créer inutilement des abstractions finalement non utilisées.

Conclusions de cette première partie

Architecturer un logiciel en dehors du cycle de développement est une pratique déconseillée dans la majorité des cas. Une vision technique doit effectivement être mise en place avant que les développements ne démarrent, mais elle doit être limité au strict minimum (just enough up front design). Il est ensuite conseillé de laisser les développeurs définirent eux même la mise en œuvre. À la condition de veiller à introduire des processus de développements rigoureux au niveau des tests, et obliger un travail régulier de refactorisation. Pour aider les développeurs dans ce travail, une équipe inter-projet de “coach” en architecture logicielle pourra être créée pour aider sur les phases sensibles de la conception du logiciel.

Nous verrons dans la suite de cet article quels sont les concepts intellectuels et philosophiques qui sont utilisés pour une bonne architecture logicielle, ainsi que les outils utilisés lors de ces différentes étapes. Enfin nous regarderons comment gérer le cas de la réutilisation de composants logiciels avec ce type d’approche.

image issue de ModeMachine

Publicités

2 réflexions sur “Concepts de l’architecture logicielle : introduction

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s