Courage, bureau des objets trouvés
|
|
Site Web Thierry Cros Courage, bureau des objets trouvés |
| | Accueil | Extreme Programming | UML, Objet | Formation | Consulting | Liens | Contact | |
Cet article présente la situation d'une équipe de développement face aux techniques "objet": UML, principes... Il traite en particulier la question de la "conception objet". Une ascension rarement facile. La réflexion porte sur:
1. UML, conception objet, gestion de projetQuels sont les outils supposés - correctement - utilisés par un développeur objet?
Langagele langage est habituellement bien connu, maîtrisé par le développeur, du moins en tant que prélude à la production d'un exécutable. Le langage en tant que moyen de rédaction, le langage vu comme un ensemble de concepts, le code lui-même comme document de conception, correspondent à un autre niveau de programmation, voire de vision de ce qu'est le métier du développeur.Concepts Objet et Principes de ConceptionLes concepts "objet" sont à la fois simples et difficilement mis en oeuvre. Inventer les objets d'un système n'est pas facile. Comprendre et ainsi traduire en programmation les interactions entre les objets est particulièrement complexe. Le peu d'intérêt - voire l'appréhension - lié au diagramme de collaboration dans UML est révélateur. De plus, le "marketing" objet frappe très fort: réutilisation, facilité de mise en oeuvre et d'intégration... Face à cela, le constat est souvent plus sombre. Il se trouve que les principes de conception objet - traduits par exemple dans les design patterns - supposent une bonne connaissance des questions de conception, par exemple la question des couplages ie des dépendances entre éléments. Par ailleurs, l'expérience généralement centrée sur une approche de type fonction/donnée ne facilite pas la vision "objet" d'un programme. Ces principes sont donc - parfois - simplement ignorés.UMLUML est le langage de modélisation objet. Modéliser signifie représenter selon un certain point de vue - à l'aide de concepts - afin de mieux comprendre. UML permet par exemple d'obtenir l'expression de besoins à partir du concept de "use case" ou bien la conception via les concepts "objet". Plus de 500 pages sont nécessaires pour décrire les spécifications de l'UML v1.4. Or, Les éléments nécessaires à une conception objet sont par eux-mêmes relativement simples: objets, interactions, messages, classes, relations telles que association, héritage, dépendance, réalisation, package... La qualité de la modélisation UML se juge à la fois sur le fond - éléments de modélisation - et sur la forme - lisibilité des diagrammes.OutilsLe modeleur UML introduit un coût supplémentaire et son utilisation n'est pas forcément bénéfique : en fonction du projet, des canaux de communication entre développeurs, d'autres techniques de modélisation - CRC cartes par exemple -pourraient être employées avec plus de succés. Enfin, le modeleur ne respecte pas toujours l'UML et cela introduit encore une difficulté supplémentaire.Conception ObjetCe terme recouvre plusieurs activités, sur différents niveaux.
Quel est le problème avec la conception objet ?L'objet est la "formule 1" du développement. Il est vrai qu'une véritable conception objet induit: plus de facilité de mise au point, d'intégration, de ré-utilisation, de maintenance évolutive.C'est - au passage - une expérience qu'il faut avoir vécu: concevoir vraiment en tenant compte des principes. Le résultat est simplement étonnant. Alors, pourquoi cela ne marche-t-il pas "toujours" aussi bien? Une difficulté de taille: ce type de conception est long, difficile, suppose des développeurs expérimentés dans ces technologies. Qui connaît le "principe de substitution" de Barbara Liskov? Qui l'applique consciencieusement? Autre élément important: les "plus" de l'objet ne sont pas toujours requis à ce niveau d'excellence. Cas typique: La bonne réaction aux changements. Un exemple classique (voir les design patterns, "fabrique abstraite") est l'encapsulation de l'interface graphique au cas où la bibliothèque changerait, par exemple passer d'une interface de type Windows à Unix... Cas rarissime. Cela ne veut pas dire qu'il n'y a pas d'intérêt à créer des packages spécifiques, simplement, le problème n'est pas dans le changement radical qui ne surviendra probablement jamais. L'intérêt réside peut-être dans la répartition des développements dans l'équipe, la meilleure testabilité... L'investissement nécessaire n'est donc pas alloué. Investissement en temps (conception longue), en moyens (formation des développeurs). Et ce n'est pas terminé. Les concepts objet sont puissants et donc à manipuler avec précaution. Une mauvaise conception peut devenir très rapidement catastrophique, blocage du codage. Des solutions existent, qui prennent en compte autant le facteur humain et les nécessités économiques, la réalité du métier pour tout dire. [ haut ] 2. Une approche alternative: les méthodes agilesLa situation :
Simple DesignFaire au plus simple, le plus simple qui puisse fonctionner.La simplicité consiste à faire avec les moyens du bord: les compétences et la bonne volonté du développeur, l'objectif qui est de répondre au besoin présent, sachant que les demandes futures sont généralement teintées d'incertitude. L'élégance d'une bonne conception objet est parfois une complication inutile. Généralement, un développeur a une solution, qui est ce qu'elle est, à un problème donné. Tests d'acceptance, tests unitairesL'Extreme Programming n'a rien à voir avec la programmation "cow-boy" et est une discipline très certainement plus contraignante que la plupart des plans de développement. Il ne s'agit de faire le plus simple possible. Ce n'est pas si simple :-). Le plus simple possible dans la plus stricte conformité aux tests. Tout le temps. Une phrase classique: "ce qui n'est pas testé n'existe pas".RefactoringLe refactoring est la clé, la pierre angulaire, le joyau du développeur. Reprogrammer un code qui ne convient pas, qui devient difficile à maintenir... qui pue. La manip est inéluctablement un redesign. Jouer encore sur la structure du code. Cas typique: la pratique dite "once, only once" qui bannit la duplication de code - sauf... :-). Plutot que d'abuser du copier/coller - prélude à de gros soucis de maintenance - autant refactorer: isoler le code en question pour le réutiliser et le maintenir plus facilement. Autrement dit: la "bonne conception" est obtenue sur demande uniquement. C'est le deuxième qui paie.C'est la différence essentielle avec la "grosse conception du début": le code "opérationnel" est rapidement produit. Ce serait un prototype qui offre déjà une valeur ajoutée à l'utilisateur, qui satisfait à un certain nombre de tests d'acceptance. Le refactoring sans test unitaire est quasiment impossible: comment oser casser un code sans pouvoir le tester et vérifier la non-regression? Quelle est la valeur de cette pratique? Comment répond-elle à la situation?
Un mot sur les "essais"Une équipe peut - dans XP - tester un certain nombre de solutions (les spikes) et ainsi se familiariser avec les techniques plus ou moins sophistiquées à mettre en oeuvre. C'est la phase exploratoire de XP, ou simplement le début d'une itération mettant en jeu une spécification particulière.Quelle est alors la véritable différence avec le prototype du "process unifié"?
[ haut ] 3. UML, je t'aime... moi non plusEt UML dans tout çà?Le problème n'est pas UML. Au contraire, l'UML en tant que langage est par définition un outil de communication.
UML dans une méthode agileUne demande du client correspond d'une certaine manière à un besoin: si le dossier de conception UML est une exigence, la question ne se pose même pas. Alors, la pratique conception-programmation-test devient simplement le garant de la conception et ce qui est patiemment représenté dans le modeleur est plus sûr.Plus généralement, l'utilisation de l'UML est à comparer à celle des CRC cards ou d'un autre moyen de communiquer le système: quels sont les objets, leurs interactions. Pourquoi de tels diagrammes sont-ils jetables? Leur implémentation immédiate dans le code, celui-ci devenant ipso facto la documentation, introduit un doublon, à l'avantage du code qui reste testable, contrairement au modèle UML. Un diagramme - même écrit manuellement - peut être affiché, c'est la "wall-communication" de XP. Un point important: certains développeurs ne "percutent" pas sur des diagrammes, leur vision du code est plus efficace et un ensemble de fichiers source représente mieux une architecture. Enfin, les pratiques de l'Agile Modeling s'appliquent parfaitement à l'UML. ConclusionLe développement reste un métier difficile, la clé est probablement une meilleure prise en compte du facteur humain dans le management de projet. L'Extreme Programming s'adresse à des êtres humains qui fabriquent des produits destinés à d'autres êtres humains. Et XP prétend pouvoir faire cela dans la joie et la bonne humeur.[ haut ] 
Commentaires bienvenus — Thierry Cros, mai 2003 ^ top ^ Retour articles XP Retour page d'accueil © 2003 - Contact |