Quand il s'agit d'un bon design OO, restez simple

Un de mes anciens élèves a un jour laissé échapper la déclaration absurde: "Je ne peux pas faire de conception orientée objet (OO); je n'ai pas l'argent!" En demandant davantage, il s'est avéré que, dans son esprit, la conception OO nécessitait un produit appelé Rational Rose, qui coûtait à l'époque environ 500,00 par siège. Dans son esprit, sans Rational Rose, le design n'était pas possible. Malheureusement, ce genre de balderdash est répandu; trop de gens pensent que l'OO est un processus de haute technologie nécessitant des outils de haute technologie. En pratique, les outils à des prix exorbitants restent inutilisés sur les étagères (ou sont largement sous-utilisés).

Dans cet esprit, dans cet article, je discute de divers outils de conception OO, de leur fonctionnement et des raisons pour lesquelles je pense qu'ils ne sont pas utiles. J'explique également comment je travaille et ce qui s'avère utile (du moins pour moi; vous êtes invité à ne pas être d'accord).

Les outils ne vous guident pas tout au long du processus

Chaque conception OO réussie que j'ai proposée a suivi à peu près le même processus:

  • Renseignez-vous sur le domaine du problème (comptabilité, planification de cours, etc.)
  • Développer, en étroite consultation avec un utilisateur en direct, une déclaration de problème qui décrit de manière exhaustive le problème de l'utilisateur, ainsi que les solutions au niveau du domaine. Ce document ne décrit pas un programme informatique.
  • Effectuer une analyse de cas d'utilisation formelle , dans laquelle je détermine les tâches nécessaires pour résoudre le problème de l'utilisateur, encore une fois, en travaillant en étroite collaboration avec un utilisateur final réel. En général , je crée un UML (Unified Modeling Language) diagramme d'activité pour tous les cas d'utilisation non négligeable. (UML est une représentation symbolique du logiciel sous forme d'image.)
  • Commencez à créer le modèle dynamique montrant les objets du système et les messages que ces objets s'envoient les uns aux autres, pendant qu'un cas d'utilisation particulier est mis en pratique. J'utilise un diagramme de séquence UML à cet effet.
  • Je capture simultanément des informations utiles sur le diagramme du modèle statique . Remarque: je ne fais jamais le modèle statique (diagramme de classes) en premier. J'ai jeté trop de modèles statiques qui se sont avérés inutiles une fois que j'ai commencé à faire le modèle dynamique. Je ne suis plus disposé à perdre le temps nécessaire pour faire le modèle statique dans le vide.
  • Les étapes mentionnées ci-dessus donnent généralement deux ou trois cas d'utilisation, après quoi je commence à coder, en fixant le modèle si nécessaire.
  • Enfin, je travaille sur un autre cas d'utilisation tel que décrit, en refactorisant le design et le code au besoin pour s'adapter au nouveau cas.

Aucun des outils de conception actuels ne vous guide tout au long de ce processus. Pour la plupart, ce sont des programmes de dessin trop chers qui ne fonctionnent pas particulièrement bien, même en tant qu'outils de dessin. (Rational Rose, que je considère comme l'un des moins capables du lot, ne prend même pas en charge la totalité d'UML.)

L'ingénierie aller-retour est un processus fondamentalement défectueux

Non seulement ces outils ne fonctionnent pas bien, mais le seul truc que ces outils exécutent - générer du code - est sans valeur. Presque tous les outils de conception OO suivent la notion d' ingénierie aller-retour dans laquelle vous commencez dans un outil de conception en spécifiant votre conception dans UML. Vous créez deux ensembles essentiels de diagrammes: le modèle statique montrant les classes dans la conception, leurs relations entre elles et les méthodes qu'elles contiennent; et le modèle dynamique, qui est une pile de diagrammes montrant les objets du système exécutant diverses tâches lors de l'exécution.

Une fois que vous avez terminé le modèle, vous appuyez sur un bouton magique et l'outil génère du code. Cependant, le code généré par l'outil n'est pas particulièrement bon pour deux raisons: Premièrement, dans de nombreux outils, des squelettes pour les définitions de classe sont créés, mais les méthodes sont simplement des stubs vides - le modèle dynamique est ignoré. Deuxièmement, aucun outil ne prend entièrement en charge UML, principalement parce qu'aucun ne le peut. UML est un langage à part entière, qui encourage l'improvisation, et une grande partie du contenu de conception réelle est exprimée dans des commentaires généralement ignorés par l'outil de conception.

En conséquence, vous piratez le code généré (la plupart des magasins le piratent vraiment). En quelques semaines, le code n'a généralement que peu ou rien à voir avec la conception originale. En fait, vous jetez efficacement votre design et retombez dans le syndrome du WHISKY (Pourquoi est-ce que quelqu'un ne "koding" pas encore?). Des années et des années de programmes qui ont échoué me prouvent que le codage sans conception augmente le temps de développement global d'au moins un facteur de trois, et aboutit à un code beaucoup plus lourd.

Vient maintenant le processus aller-retour: vous ouvrez votre outil, appuyez sur le bouton magique et importez le code, en reconstruisant théoriquement la conception afin qu'elle reflète l'état réel du code. Cependant, une telle ingénierie inverse ne fonctionne pas. Les outils créent généralement de nouveaux diagrammes de classes, mais ne mettent jamais à jour le modèle dynamique. Étant donné que le modèle dynamique est au cœur du processus, votre conception est désormais sans valeur à moins que vous ne la mettiez à jour manuellement, ce qui est rarement fait.

Au risque de me répéter, le processus aller-retour encourage les programmeurs à ignorer entièrement la conception et à ne coder que du code, puis à faire de l'ingénierie inverse du code en images de temps en temps. Dans cette situation, cependant, les programmeurs ne conçoivent pas; ils piratent du code, puis créent des images du désordre qui en résulte. Le piratage n'équivaut pas au design.

Bien que la conception soit en effet un processus itératif (la conception change au fur et à mesure que le code est développé), vous devez commencer une itération en modifiant d'abord la conception, puis en refactorisant le code pour refléter la nouvelle conception. Pour ce faire, vous devez être en mesure de spécifier l'ensemble du produit logiciel dans l'outil (lorsque vous appuyez sur le bouton magique, un programme entièrement fonctionnel est généré) et le processus est unidirectionnel sans rétro-ingénierie. mécanisme.

Les outils CASE

Les outils CASE (génie logiciel assisté par ordinateur) comme Rational Rose placent généralement l'ingénierie aller-retour au cœur du produit. Cependant, comme l'ingénierie aller-retour ne fait rien d'utile, de nombreux développeurs utilisent les outils comme des programmes de dessin coûteux. Parmi les outils disponibles, je pense que trois méritent d'être considérés (bien que je n'en utilise aucun):

  • L'outil gratuit et open source ArgoUML, écrit en Java, fait un assez bon travail de création de diagrammes UML. La dernière version tente même de vous guider tout au long du processus (avec un succès marginal jusqu'à présent, mais c'est un bon début).
  • GDPro d'Embarcadero, anciennement distribué par Advanced Software, offre un bon support pour un groupe travaillant sur une conception de logiciel unique, mais présente également des lacunes dans ce département. Par exemple, un concepteur ne peut pas extraire un diagramme de modèle dynamique tout en verrouillant automatiquement les classes associées aux objets sur le modèle dynamique.
  • Together ControlCenter de TogetherSoft évite le problème de déclenchement inverse en ne le faisant pas. Le code et le dessin apparaissent simultanément à l'écran et lorsque vous en modifiez l'un, l'autre change automatiquement. Cependant, ControlCenter ne prend pas bien en charge les groupes de programmeurs.
  • Je devrais également mentionner brièvement Visio de Microsoft. Visio est un programme de dessin qui prend en charge UML en quelque sorte, mais sa prise en charge imite l'interface utilisateur misérable de Rational Rose. Différents modèles de dessin pour les formes UML dans Visio fonctionnent mieux que la prise en charge UML intégrée, dont un dans la section "Goodies" de mon site Web.

Donc, si je pense si mal à ces outils, que dois-je utiliser? Les outils de conception OO les plus productifs sont de loin un tableau blanc (une pièce avec des tableaux blancs mur-à-mur, du sol au plafond est idéale) et des blocs Post-it de la taille d'un flip-chart, des feuilles que vous pouvez décoller et coller sur le mur. Je les ai utilisés pour concevoir des projets importants avec beaucoup de succès. De plus, travailler sur un tableau blanc prend beaucoup moins de temps que de lutter avec un outil OO CASE.

La seule difficulté avec l'approche tableau blanc est de capturer les informations sur le tableau. Les tableaux blancs qui impriment existent, mais ils sont chers, disgracieux et trop petits. Un produit matériel soigné qui suit le mouvement d'un stylet sur un tableau blanc et capture les traits du stylet dans l'ordinateur. D'autres tableaux blancs fonctionnent comme des tablettes numériques géantes. Cependant, ces solutions s'avèrent trop limitatives; la conception se déroule simultanément sur des tableaux blancs dans plusieurs bureaux, sur des serviettes, sur des bouts de papier, etc. Vous ne pouvez pas transporter un tableau blanc d'impression de 300 livres au café local.

Alors qu'est-ce qui fonctionne

Alors, que faire une mère? Comment capturer ces artefacts pour les archiver dans l'ordinateur afin qu'ils rédigent une documentation raisonnable telle quelle, sans avoir à les transférer vers un programme de dessin?

La solution:

  1. Un appareil photo numérique
  2. Un merveilleux logiciel appelé Whiteboard Photo de Pixid

Une photo numérique produit malheureusement souvent des images insatisfaisantes pour la documentation. Pour compenser, Whiteboard Photo transforme les images numériques en quelque chose d'utile. Les images valent vraiment mille mots, ici. La figure 1 montre une photo numérique typique d'un tableau blanc.

La figure 2 illustre un autre exemple.

La figure 3 montre comment Whiteboard Photo transforme la figure 1.

Et voici à quoi ressemble la figure 2 après que Whiteboard Photo ait fait sa magie.

Comme le montrent les images, la différence est incroyable. Pour transformer l'image originale en version nettoyée, j'ai simplement frappé Ctrl-L. Le logiciel a automatiquement trouvé les limites du tableau blanc, corrigé de la distorsion causée par la prise de vue sous un angle (nécessaire pour éviter l'éblouissement du flash), a sélectionné les lignes du dessin et les a dessinées. Tout ce dont le produit a besoin pour atteindre la perfection est la reconnaissance de l'écriture manuscrite, mais je suis rose chatouillé avec lui tel quel. Je peux maintenant produire des dessins de qualité documentation directement à partir du tableau blanc d'origine, sans perdre des heures à entrer le dessin dans une excuse boiteuse pour un outil CASE.

Rester simple

D'après mon expérience, en matière de conception OO, les outils low-tech fonctionnent le mieux. En effet, ils sont plus rapides, plus faciles à utiliser et fonctionnent bien dans les environnements collaboratifs. Jusqu'à présent, j'ai trouvé que la combinaison d'un tableau blanc, d'un appareil photo numérique et d'un tableau blanc photo offre la meilleure méthode pour intégrer des conceptions de programme dans une machine.

Allen Holub fournit des services de conseil, de formation et de mentorat en conception OO, processus OO et programmation Java. Il présente régulièrement un atelier de conception OO intensif pour ceux qui souhaitent développer rapidement leurs compétences OO. (Trouvez plus d'informations sur //www.holub.com.) Allen travaille dans l'industrie informatique depuis 1979, plus récemment en tant que directeur de la technologie chez NetReliance, Inc. Il est largement publié dans des magazines (Dr. Dobb's Journal, Programmers Journal, Byte et MSJ, entre autres). Allen a huit livres à son actif, dont le dernier - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - couvre les pièges et les pièges du threading Java. Il enseigne le design OO et Java pour l'Université de Californie, Berkeley Extension (depuis 1982).

En savoir plus sur ce sujet

  • Pour accéder à l'outil de conception gratuit et open source ArgoUML, accédez à

    //argouml.tigris.org/

  • GDPro d'Embarcadero peut être trouvé à

    //www.embarcadero.com

  • Vous trouverez plus d'informations sur TogetherSoft ControlCenter à l'adresse

    //www.togethersoft.com

  • La page d'accueil de Microsoft Visio

    //www.microsoft.com/office/visio/default.htm

  • Allez à la page produit Pixid Whiteboard Photo pour plus d'informations sur cet outil intéressant

    //www.pixid.com/home.html

  • Le site Web d'Allen Holub présente sa page «Goodies», où vous trouverez des conseils de conception OO, des règles de programmation empiriques et des notes de certains des exposés d'Allen

    //www.holub.com/goodies/goodies.html

  • L'index de conception et de programmation orientée objet de JavaWorld contient de nombreux articles traitant de la conception

    //www.javaworld.com/channel_content/jw-oop-index.shtml

  • Vous trouverez plus grande critique sur ce produit dans JavaWorld de l' indice de commentaires sur les produits

    //www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml

  • Lire la suite dans le commentaire JavaWorld de l » Index Commentaire

    //www.javaworld.com/news-reviews/jw-nr-commentary.shtml

  • Pour obtenir des conseils et des didacticiels sur les modèles de conception, les outils de développement, le réglage des performances, la sécurité, les tests, etc., inscrivez-vous à notre newsletter Applied Java

    //www.javaworld.com/subscribe

  • Exprimez-vous dans notre discussion sur la théorie et la pratique de la programmation

    //forums.idg.net/[email protected]@.ee6b806

  • Vous trouverez une multitude d'articles liés à l'informatique provenant de nos publications sœurs sur .net

Cette histoire, "Quand il s'agit d'un bon design OO, restez simple" a été initialement publiée par JavaWorld.