• Animateur(s): Vincent Hardion
• Secrétaire(s): Vincent Delos
• Participants: Ludovic Léau-Mercier, Alexandre Claude , Alexandre Granier, Soraya Arias, Alain Coron, Stéphane Deraco, Patrice Ringot, Benjamin Dexheimer, Edyta Bellouni, Vincent Hardion, Vincent Delos
• Agenda: (présentations, thématiques de discussions, …)
• Documents de référence:
• Date: 30 septembre 2011 de 14h40 à 15h55
• Lieu: Salle b205
• Premier vote:
• Choix définitif: 14

L'intégration des composants logiciels est devenue une pratique courante dans le développement logiciel aujourd'hui. L'introduction de la programmation Orienté Objet et de la programmation modulaire a contribué à codifier et populariser d'autant plus ces bonnes pratiques. Mais celle-ci ne va pas sans poser problème dans la mesure où elle questionne la qualité de l'architecture globale et la justesse de ses interfaces.

Dès lors quelles sont les méthodes et les règles à appliquer pour définir les architectures logicielles et le partage de composants ?

Le groupe de travail qui s’est tenu le 30 septembre a regroupé 11 personnes de divers instituts et de diverses expériences. Le débat s’est déroulé autours de thèmes principaux : les méthodes pour créer de bonnes architectures, les bonnes pratiques pour rendre les composants réutilisables et, enfin, les outils utilisés pour construire les architectures et contrôler la qualité d’intégration.

Méthodes

Les méthodes de développement logiciel ont une grande influence sur la façon d’architecturer le logiciel. La discussion s’est tournée vers 2 principales méthodes :

Les méthodes Agiles donnent une architecture émergente tout au long du projet. La définition de l’architecture se construit en même temps que les besoins se précisent.

• La méthode de développement piloté par les tests (Test Development Driven ou TDD) permet d’assurer de construire une architecture testable. Cela donne l’avantage de fournir des tests unitaires très tôt dans le cycle (coût masqué dans le développement). Ces tests peuvent servir de documentation dans le cadre d’une API.
• Basé sur une itération courte (15j) : 1ère Spécification vague > Test > Implémentation rapide > Refactoring > Architecture > 2ème spécification etc …
• Ces méthodes peuvent convenir dans le cas de spécification non stable ou en évolution constante.
• Un autre avantage lié à l’Intégration Continue permet de stabiliser les interfaces et de contrôler ses changements.

La méthode de développement piloté par les modèles (Model Development Driven ou MDD) dont le principe est de définir l’architecture définitive en premier à l’aide des outils UML.

• Basé sur une itération plus longue (3 mois minimum) : Spécification complète ou partiel définitive → Architecture → Code → Test …
• A l'opposé de l’Agile, le « Model Driven Development » clôturera la séquence de développement par les tests, vérification et validation.
• Un des avantages de cette méthode est de fournir la documentation technique à la fin du projet avec le modèle UML.
• Un autre avantage serait de générer une partie du code automatiquement.

En effet quel que soit la méthode choisie en amont (tdd, mdd, agilité, ?), chacune présente ses avantages et inconvénients. Savoir en extraire les concepts fondamentaux et l'esprit de chacune d'elles, en fonction des contraintes de terrain et du projet, doit primer sur une approche rigoriste en toute circonstance. Il peut être intéressant aussi de savoir astucieusement s'inspirer des différentes méthodes de manière adaptée aux objectifs du cahier des charges.

Bonnes pratiques

Dans le cadre d’une architecture et de partage de composants, la discussion renvoie presque toujours à la notion de dépendance avec pour objectif un faible couplage entre les classes.

Quelques principes ont émergé lors de notre rencontre :

• KISS : Keep It Simple, Stupid : Ne pas complexifier les composants au delà du besoin. La question de la réutilisabilité ne peut se poser que lors du partage.
• Single Responsability : Le principe de la « responsabilité unique » pour chaque élément est revenu plusieurs fois lors du débat. Par exemple, un modèle de conception Observateur doit remplir exclusivement cette fonction et aucune surcharge n'est souhaitée à ce niveau. “1 algo == 1 classe && 1 classe == 1 algo”
• SOC : Separation Of Concern : L’idée est de bien séparer les différentes fonctionnalités ou comportement d’un programme à l’aide de modules ou de classes. Par exemple dans le modèle MVC, il faut bien distinguer la vue du modèle.

Dans l’optique d’une éventuelle réutilisabilité, le suivi de bonnes pratiques devrait suffire. A ce titre l'hyper-réutilisabilité systématique des composants peut même s’avérer pénalisante.

Les bonnes pratiques définies ci-dessus ne sont que des pistes à suivre et il en existe sûrement d’autres à partager …

Partage de composant

Le concept de l'intégration n'est-il pas trop abstrait ?

Les contraintes d’un composant (performances, complexité algorithmique, mémoire consommée …) doivent être connues avant de l’intégrer dans une application. De plus divers paramètres contraignent le partage : le langage, l’intégration, le cycle de vie …

Enfin, il reste des questions que nous n’avons pu aborder en profondeur comme la forme du partage : Doit-il se faire sous la forme d’une librairie, d’un framework, d’une application externe … ?

Outils

Ils existent des outils pour aider à développer, à partager, à contrôler …

Parmi lesquels :

• SONAR a été cité comme un bon auditeur de code, particulièrement versatile, il analyse le Java, C, C#, VB et permet de qualifier l'architecture, les conventions de codage, les commentaires, tests unitaires, duplications, bogues potentiels … Il est lui-même basé sur d'autres outils d'analyse statique (Java : Checkstyle, PMD, FindBugs et Clover ; C++ : pCpCheck, Vera++, GoCv …).
• BOUML le designer open source UML a fait l'unanimité dans le cercle de discussion, apprécié pour son côté multi-plateformes et sa rapidité.
• Plume : Ce site Web qui peut être vu comme un outils de partage de composant réutilisable.
• Modelio : outils de modélisation supportant plusieurs standards (dont UML2, SysML, …) et passé Open Source fin 2011 ; disponible nativement en 32bits pour Windows et Linux.

Enfin les IDE actuels, comme Eclipse, intègrent les outils pour aider le développement des architectures.

Conclusion

Le groupe de travail a montré la forte demande dans le partage de connaissances. La mise en place d’un forum de discussion ou d’une mailing-lits, ainsi que le partage d’articles permettrait d’échanger les différentes expériences.

En même temps, l’aspect collectif de la discussion a permis de faire émerger des solutions pragmatiques, issues de l’expérience de chacun. Cette expérience devrait être renouvelée.

SoC : http://en.wikipedia.org/wiki/Separation_of_concerns

KISS : http://en.wikipedia.org/wiki/KISS_principle

Single Responsability : http://en.wikipedia.org/wiki/Single_responsibility_principle

Agile : http://en.wikipedia.org/wiki/Agile_software_development

TDD : http://en.wikipedia.org/wiki/Test-driven_development

CI : http://en.wikipedia.org/wiki/Continuous_integration

MDD : http://en.wikipedia.org/wiki/Model-driven_development

Sonar : http://www.sonarsource.org/

Bouml : http://bouml.free.fr/

Plume : http://www.projet-plume.org/fr

Modelio : http://www.modelio.org/