Initiation à l'architecture logicielle - Partie 1

Publié
Commentaires Aucun

Petit mot d’introduction

Bien le bonjour à tous. J’ai décidé d’écrire les articles ci dessous suite à une discussion avec ami.
Bien qu’excellent développeur, celui-ci ignore la pluart des principes de base de l’architecture logicielle.

Voici donc quelques petits articles, faciles à lire, qui vous apporteront toutes le notions de base en architecure logicielle dont vous aurez besoin lors de vos développements.

Qu’est-ce que l’architecture logicielle ?

L’architecture logicielle est la facon dont sont agencés les différentes fonctionnalités de votre logiciel.

Imaginez un pont. Si vos composants. c’est à dire les briques de votre pont sont correctement positionnées, votre pont traversera les millénaires et supportera aussi bien un homme qu’une charette ou une voiture.

Si vous empilez les blocs au hasard, vous avez toute les chances que votre édifice se casse la figure au premier usager.

Voici deux versions d’un même logiciel.
soft_laid
soft_beau

Il en va de même pour l’architecture logicielle. Si vous y allez au hasard, vous allez obtenir une construction organique et anarchique truffée de bugs qui sera un enfert à maintenir.
Si vous organisez avec attention votre programme, celui-ci sera plus performant, facile à maintenir et à faire évoluer.

Quand faire de l’architecture ?

Étant donné que l’architecture va conditionner l’ensemble de vos développements, il conviens d’y penser le plus tôt possible. Il faut que votre achitecture soit mise au propre avant d’attaquer la moidre ligne de code ou le moindre diagramme de classes UML.
On s’attaque à l’architecture d’un logiciel juste après la définition définitive du cahier des charges.

workflow

Quelle différence entre architecture et design ?

C’est une question d’échelle, mais il n’existe pas de limite nette.

Reprennons un exemple dans le batiment. Construisons une cathédrale. La sculpture de la gargouille en haut à droite, c’est du design. Choisir de faire du gothique ou du roman pour l’ensemble de la cathédrale, c’est de l’architecture.

Utiliser un singleton, c’est du design. En revanche, décider d’un modèle à deux couches, c’est de l’architecture.

Grands principes architecturaux

Il existe un principe de base qui devra être appliqué au mieux, et ce pour n’importe quel architecture:

La séparation des problématiques (separation of concerns).

L’idée de la séparation des problématiques, c’est que chaque fonctionnalité du logiciel doit être située dans un périmètre clairement établi, et ne pas se mélanger aux autres.
Par exemple, il est très mauvais de mélanger dans la même classe un appel à la base de donnée (1ere problématique) et la génération de code HTML pour l’affichage (2ème problématique).

Il est beaucoup plus opportun de faire deux classes, l’une qui ne fera QUE des appels aux bases de données, et une seconde, qui ne fera QUE de la génération de code HTML.
Un code qui fait n’importe quoi dans n’importe quel ordre est dit spaghetti ou organique, et est à éviter à tout prix.

Pourquoi séparer les problématiques ?

- Si vous avez une modification à faire pour une fonctionnalité en particulier, vous n’êtes plus obligé de casser tout votre code. Il suffit juste de casser le bloc qui s’occupe de cette fonctionnalité.
- Vous pouvez réutiliser facilement le bloc si vous avez besoin de ce morceau de code ailleurs.

On remarquera donc que ce principe implique de limiter au maximum les dépendances entre les différents composants qui formeront votre logiciel.

Ceci nous amène au second grand principe:

La réutilisabilité.

On ne devrait jamais avoir à refaire quelque chose que l’on a déjà fait. Il faut donc que vos blocs soient organisés de telle facon qu’il soit possible de les réutiliser facilement sans dupliquer le code qu’ils contiennent.

Pourquoi favoriser la réutilisabilité ?

- Réecrire du code (ou des services) prends du temps
- Du code (ou des services) dupliqué utilise de l’espace mémoire pour rien
- Du code (ou des services) dupliqué, ca fait plus de code à déboguer
- Si on veut modifier la fonctionnalité, on sera obligé de modifier aussi tout le code dupliqué.

Architecture orientée objet

Il existe de nombreux types d’architectures, cet article se concentre sur l’architecture dite orientée objet. ie. Nous allons travailler avec des objets qui vont communiquer ensemble, et nous allons voir comment agencer tout ce petit monde au mieux.
Le sujet étant immense, je vais me limiter ici au modèle 3 couches.

Notion de couches

Dans la suite de l’article, vous alez beaucoup entendre parler de couches. Une couche (layer en anglais) est un des plus haut niveau de regroupement de fonctionnalités.
C’est donc un gros rassemblement de classes qui possèdent les même types de fonctionnalités. Ces gros blocs vont être asemblés les uns sur les autres, d’où leur nom de couches.

On distingue dans la plupart des logiciels les gros groupes de fonctionnalités suivants:

- Présentation : Les classes qui gèrent l’affichage de l’interface utilisateur, la génération du code HTML, etc.
- Métier : Les classes qui font des traitements logiques ou des calculs sur nos données
- Accès aux données : Les classes qui vont chercher nos données brutes. On va trouver ici les classes de lecture de fichiers, d’accès aux base de données, etc.
- Le modèle : Les classes qui vont contenir temporairement nos données.

On peut aussi trouver des couches transversales de:

- Sécurité : Ici se trouvent les classes qui vont s’assurer qu’une opération est autorisée
- Logging : Ici se trouvent les classes spécialisées dans la gestion des logs

Ci dessous un petit schéma de l’organisation classique des différentes couches (modèle 3 couches).

trois_couches

Bien entendu, il est possible d’avoir plus ou moins de couches suivant le type d’architecture que vous aurez retenu.

De la bonne utlisation des couches

A présent que vous savez ce qu’est une couche, nous allons voir comment les faire communiquer et comprendre pourquoi on les empile dans cet ordre : Présentation / Métier / Accès aux données.

L’idée c’est que chaque fonctionnalitée en appelle une autre. Par exemple:
Pour afficher un résultat à votre utilisateur (Couche présentation), vous avez besoin d’effectuer des calculs (couche métier), pour effectuer ces calculs, vous avez besoin de données brutes sur lesquelles travailler (Couche accès aux données).
Vous empilerez donc vos couches dans l’ordre suivant:
Présentation —— Qui appelle —-> Métier —— Qui Appelle ——> Accès aux données.

Rappelez vous ce que nous avons vu au dessus. Une des règles de base à respecter implique de limiter les dépendances entre les différents composants de votre logiciel. Donc, on devra limiter au maximum les dépendances entre vos différentes couches.

Le petit schéma suivant vous l’illustre:

dependances

L’idée globale est que les différents composants de votre logiciel ne devraient toujours communiquer QUE dans un seul sens (Et ce entre autre pour éviter les dépendances cycliques). Pour nos couches, ca se fera du haut vers le bas.

Si vous vous retrouvez à appeller des fonctions de la couche métier depuis votre couche d’accès aux données, vous avez un gros souci: Votre couche métier est dépendante de votre couche d’accès aux données, et votre couche d’accès aux données deviens dépendante de votre couche métier….

En gros, vous n’avez plus de couches.

Dans le prochain article, nous verrons plus en profondeur comment concevoir chaque couche.

Auteur

Commentaires

Commentaires fermés pour cet article.

← Plus anciens Plus récents →