10 principes de conception de syst�mes logiciels

Ma participation a des projets de r�alisation de logiciels m'am�ne souvent � utiliser ou rappeler quelques principes fondamentaux de conception. J'ai souhait� � travers cet article partager ma vision de cette activit�. Ces principes sont en fait assez g�n�riques et peuvent souvent �tre appliqu�s quelque soit le niveau d'abstraction de l'objet � r�aliser (architecture applicative, architecture technique, impl�mentation en Java ou Ruby, etc.). On retrouve bien s�r les principes de base du paradigme objet ainsi que d'autres plus g�n�rales et d'autres plus pragmatiques.

J'essaye de r�sumer chacun de ces principes par une phrase simple � l'imp�ratif pr�sent avec uniquement un verbe et un compl�ment d'objet. Ceci permet de rendre ces r�gles courtes et facilement m�morisables. Elles pourraient �tre la base d'un mantra du concepteur/d�veloppeur :-)

"Encapsulez l'impl�mentation"
"S�parez les responsabilit�s"
"Minimisez les d�pendances spatiales, temporelles et structurelles"
"R�duisez les �tats"
"Echouez rapidement"
"Donnez de la signification"
"V�rifiez les hypoth�ses"
"Param�trez par convention"
"Prot�gez les variations"
"Concevez extensible et adaptable"
Conclusion

"Encapsulez l'impl�mentation"

Ce principe de base du paradigme objet, �galement appel� Information hiding , implique une s�paration nette entre l'interface d'utilisation d'un composant logiciel et son impl�mentation. Cette derni�re doit �tre compl�tement inaccessible � l'utilisateur du composant. J'utilise le terme "composant logiciel" car celui ci peut prendre des formes diverses et vari�es : une fonction, un objet, etc. L'utilisation du principe d'interface, comme en Java, permet de physiquement s�parer ces deux �l�ments.

"S�parez les responsabilit�s"

En anglais Separation of concerns . Principe fondamental permettant de modulariser un syst�me en s�parant clairement les r�les que tiennent chacun des composants de ce syst�me. Cette s�paration peut �tre arbitraire mais on peut n�anmoins identifier des m�triques permettant de d�terminer les d�s�quilibres de responsabilit�s dans un syst�me (nombre de classes �lev�es dans un package, nombre de lignes dans une fonction, nombre d'op�rations dans une classes)
On peut aboutir � une identification efficace des responsabilit�s, notamment en conception objet par l'utilisation de techniques comme les CRC cards . Dans le cadre d'une application on trouve souvent au minimum la s�paration des responsabilit�s techniques entre les fonctions m�tiers et IHM avec le pattern MVC

"Minimisez les d�pendances spatiales, temporelles et structurelles"

Principe, � mon avis, extr�mement fondamental qui impose de d�finir clairement quelles sont les d�pendances d'un composant. Pour chaque d�pendance on tentera de d�terminer ses diff�rentes qualit�s d�crites ci-apr�s. L'objectif �tant pour chacunes de ses d�pendances de les minimiser et ainsi d'appliquer le principe de couplage faible .

La d�pendance spatiale est li�e � la localisation des composants. L'utilisation d'un service de nommage (DNS, JNDI, etc.) ou d'un registre permet de la r�duire. Le m�canisme le plus simple reste � mon sens l'URI. Ce qui encore une fois nous ram�ne vers l'int�gration de type REST (voir mon pr�c�dent billet � ce sujet ).

La d�pendance temporelle a trait aux concepts de synchronisme et d'asynchronisme . Un syst�me sera moins d�pendant d'un autre syst�me s'il �change avec lui de mani�re asynchrone car la disponibilit� d'un composant en d�pendance � un instant "t" n'est plus n�cessaire. Cela ne veut pas dire que notre syst�me est compl�tement tol�rant aux pannes puisqu'il est maintenant d�pendant d'une file de message , n�anmoins la fiabilit� de cette d�pendance technique est facilement g�rable par un m�canisme de type Store-and-Forward (on parle alors de Reliable Messaging). Afin de bien se repr�senter la notion d'asynchronisme et la notion de commit � deux phases n�cessaires aux interactions synchrones voici un lien vers un article de Gregor Hope sur l'asynchronisme .

La d�pendance structurelle traite des structures de donn�es n�cessaires � une interaction ainsi que des interfaces d'invocation (signature d'op�rations pour faire plus simple). Plus la structure sera rigide et plus la d�pendance sera forte. Il vaut donc mieux oublier les formats de donn�es binaire et se diriger vers les formats XML et leurs vastes possibilit�s (XPath, XQuery, XML Schema, etc.). La d�pendance structurelle nous am�ne au sujet du versioning qui consiste � pouvoir servir plusieurs versions d'un m�me service � plusieur clients diff�rents.

"R�duisez les �tats"

C'est pour moi le principe fondamental permettant la r�duction des causes d'erreurs en diminuant le nombre d'�tat concurrents dans un syst�me � un instant t. Id�alement, les zones de stockage d'�tat d'un syst�me logiciel peuvent se r�duire � la pile d'ex�cution et la base de donn�es.
On retrouve souvent une troisi�me zone d�nomm�e Session dans les d�veloppements web, notamment en Java et en .Net, mais absente de PHP dans son mod�le de programmation par d�faut.
Ce point rejoint une des cons�quences de la programmation fonctionnelle, � savoir la suppression des variables d'�tats par une programmation non imp�rative. Cet article explique clairement pourquoi les langages fonctionnels "purs" ont peu d'�tats concurrents de par leurs conceptions.

"Echouez rapidement"

Ce principe, en anglais Fail fast , est associ� au principe V�rifiez les hypoth�ses . Lorsque les hypoth�ses ou besoins d'un traitement ne sont pas remplies (absence de param�tres, erreur lors de l'utilisation d'un autre composant) le composant doit �chouer de la mani�re la plus explicite et incontournable possible, avec une exception par exemple. Lorsque un traitement ne se d�roule pas correctement l'erreur doit �tre report�e imm�diatement. Cette erreur peut �galement mettre en oeuvre le principe "Donnez de la signification" : connaitre si possible la cause de l'erreur, sa description et surtout les actions permettant de la corriger.

"Donnez de la signification"

Ce principe a pour objet de fournir la s�mantique la plus claire possible � tout nommage (variable, classe, r�pertoire, composants, etc.). Le code ou l'environnement est ainsi auto-signifiant et n'a pas besoin d'�l�ments de signification suppl�mentaire sous forme de documentation. Si possible, comme avec l'outil javadoc en Java, le code doit inclure sa documentation. Le nommage ainsi que la signification s'affine au f�r et � mesure de la r�alisation, il est donc n�cessaire de pouvoir effectuer facilement des modifications dans le code source gr�ce aux fonctions de refactoring.

"V�rifiez les hypoth�ses"

Si une hypoth�se v�rifi�e par un composant n'est pas remplie la r�gle Echouer rapidement est � appliquer. Ce principe est une cons�quence du principe Minimisez les d�pendances , chaque fois qu'une d�pendance est n�cessaire il faut s'assurer de sa validit� � l'ex�cution. Chaque fois que le d�veloppeur se dit "tel composant doit me fournir tels �l�ments" (telles donn�es ou une donn�e format�e de mani�re particuli�re par exemple) le composant doit v�rifier et lever une erreur en cas de condition non remplie. Une technique de programmation est associ�e � ce principe : la programmation par contrat . Ce type de programmation se rapproche �galement de la programmation d�fensive m�me si cette derni�re vise en premier lieu � assurer un meilleur niveau de s�curit� du composant.

"Param�trez par convention"

Chaque composant n�cessite des param�tres susceptible de modifier son comportement. Ces param�tres doivent chacun avoir une valeur par d�faut ou pouvoir se d�duire � partir du nommage d'un autre composant. Un exemple classique dans un framework MVC : la redirection vers une vue nomm�e "mavue" sera utilis�e par le framework qui cherchera par exemple le fichier "mavue.jsp" dans son r�pertoire d'ex�cution. Le param�trage par convention �vite l'�clatement et la croissance du param�trage d'un syst�me.

"Prot�gez les variations"

Ce principe est utilis� lorsque des clients d�pendent du composant construit. Il implique de pr�voir les modifications d'interface afin de ne pas briser l'utilisation du composant. L'information sur l'obsolescence d'une interface est n�anmoins pertinente, c'est par exemple la fonctionnalit� "deprecated" fournit par le langage java et son outil javadoc. Ce principe est tr�s li� au versionning, qui est un sujet � part enti�re et qui fera l'objet d'un futur article. Ce principe est souvent associ� � celui d�nomm� Open-Closed .

"Concevez extensible et adaptable"

Ce principe est tr�s g�n�ral et permet respectivement d'enrichir ou de modifier le composant construit. Ces principes ne sont, bien s�r, pas indispensables, notamment celui d'extensibilit� qui peut �tre assez co�teux � mettre en place. N�anmoins le principe d'adaptabilit� est assez facile d'acc�s et peut apporter une grande �volutivit�.

L' extensibilit� peut �tre fournie par la mise en place de m�canisme comme les plugins que l'on trouve pour des logiciels fonctionnellement tr�s riche (Eclipse, Photoshop, etc.). L'h�ritage est un m�canisme d'extension plus fin qui trouve ses origines dans le paradigme objet.

L' adaptabilit� implique d'identifier les �l�ments variables du composant et de les extraire en tant que param�tres du composant. La notion d'interface ou la fermeture dans les langages fonctionnels, permettent � un utilisateur d'un composant de fournir le traitement que celui-ci utilisera et donc d'adapter le comportement non pas par les donn�es mais par un traitement. C'est d'ailleurs une des forces de framework d'injection de d�pendance comme Spring en Java que de pouvoir offrir des interfaces et des impl�mentations par simple param�trage offrant ainsi un excellente adaptabilit�. Dans les langages fonctionnels comme ruby ou python, le passage de fonctions en param�tres ou le yield permettent une gestion plus fine de ce code sp�cifique � ins�rer.

Conclusion

Mon billet sur les langages de programmation se concluait par l'importance qui devait �tre accord�e � l'activit� de conception. Cet article tente humblement de livrer quelques principes g�n�raux de conception de syst�mes logiciels que j'ai pu exp�rimenter et dont j'ai pu appr�cier la puissance. Afin de compl�ter cet article il est int�ressant de r�fl�chir � la mani�re de v�rifier automatiquement chacun de ces points.

J�r�mie Grodziski