Quels sont les avantages de la modélisation de systèmes logiciels par rapport à tout faire en code?

La plupart, sinon tous les informaticiens que je connais, pensent qu'il est avantageux de modéliser un logiciel avec UML ou d'autres types de diagrammes avant de coder. (Ma question ne concerne pas spécifiquement UML, il pourrait s'agir d'une description graphique ou textuelle de la conception du logiciel.)

Je n'en suis pas si sûr. La raison principale est: le code ne ment pas. Il est vérifié par le compilateur ou l'interpréteur. Nous espérons qu'il a des tests automatisés et doit passer une analyse de code statique. Si un module ne s'interface pas correctement avec un autre module, cela est généralement évident dans le code car vous obtenez un message d'erreur.

Tout cela ne peut pas être fait avec des diagrammes et autres documents. Oui, il existe des outils qui vérifient UML, mais tout ce que j'ai vu jusqu'à présent est très limité. Par conséquent, ces documents ont tendance à être incomplets, incohérents ou simplement faux.

Même si les diagrammes eux-mêmes sont cohérents, vous ne pouvez pas être sûr que le code les implémente réellement. Oui, il existe des générateurs de code, mais ils ne génèrent jamais tout le code.

J'ai parfois l'impression que l'obsession de la modélisation résulte de l'hypothèse que le code doit inévitablement être un gâchis incompréhensible que les architectes, les concepteurs ou d'autres personnes bien rémunérées qui ont une vue d'ensemble ne devraient pas avoir à gérer. Sinon, cela coûterait beaucoup trop cher. Par conséquent, toutes les décisions de conception doivent être éloignées du code. Le code lui-même devrait être laissé à des spécialistes (singes de code) qui sont capables de l'écrire (et peut-être de le lire) mais n'ont rien d'autre à faire. Cela était probablement logique lorsque l'assembleur était la seule option, mais les langages modernes vous permettent de coder à un niveau d'abstraction très élevé. Par conséquent, je ne vois plus vraiment le besoin de modélisation.

Quels arguments pour la modélisation des systèmes logiciels me manquent?

Soit dit en passant, je crois que les diagrammes sont un excellent moyen de documenter et de communiquer certains aspects de la conception de logiciels, mais cela ne signifie pas que nous devrions baser la conception de logiciels sur eux.

Clarification:

La question a été suspendue pour manque de clarté. Permettez-moi donc d'ajouter quelques explications:

Je demande s'il est logique d'utiliser des documents (non codés) qui modélisent le logiciel comme la principale source de vérité sur la conception de logiciels. Je n'ai pas le cas en tête lorsqu'une partie importante du code est générée automatiquement à partir de ces documents. Si tel était le cas, je considérerais les documents eux-mêmes comme du code source et non comme un modèle.

J'ai énuméré quelques inconvénients de cette procédure qui me font me demander pourquoi tant de gens (selon mon expérience) la considèrent comme la meilleure façon de faire de la conception de logiciels.

L'avantage de la modélisation des systèmes logiciels par rapport à tous dans le code est: je peux adapter le modèle sur un tableau blanc.

Je crois beaucoup à la magie de communiquer sur une seule feuille de papier. Si j'ai essayé de mettre du code sur le tableau blanc, lors de l'enseignement de notre système à de nouveaux codeurs, il n'y a tout simplement pas de code au niveau d'abstraction nécessaire qui s'adapte sur un tableau blanc.

Je connais l'obsession de la modélisation dont vous parlez. Les gens font des choses parce que c'est comme ça qu'ils ont fait avant, sans se demander pourquoi ils le font. J'en suis venu à l'appeler formalisme. Je préfère travailler de manière informelle car il est plus difficile de cacher la bêtise derrière la tradition.

Cela ne signifie pas que je ne sortirai pas de temps en temps une esquisse UML. Mais je ne serai jamais le gars qui vous demande de rendre un document UML avant de pouvoir coder. Je pourrais vous demander de prendre 5 minutes et de trouver QUELQUE manière d'expliquer ce que vous faites parce que je ne supporte pas l'existence de code qu'une seule personne comprend.

Fowler a identifié différentes façons dont les gens utilisent UML qu'il a appelé les modes UML . La chose dangereuse avec chacun d'eux est qu'ils peuvent être utilisés pour se cacher de faire un travail utile. Si vous le faites pour coder à l'aide de la souris, j'en ai vu beaucoup essayer. Je n'ai vu personne faire que ça marche vraiment. Si vous le faites pour communiquer, vous feriez mieux de vous assurer que les autres vous comprennent. Si vous le faites pour concevoir, vous feriez mieux de trouver et de résoudre les problèmes pendant que vous travaillez. Si tout se passe bien et que vous passez la majeure partie de votre temps à embellir les flèches, arrêtez-vous et retournez au travail.

Plus important encore, ne produisez pas de diagrammes qui devraient être valables plus d'une journée. Si vous le pouvez, vous avez échoué. Parce que le logiciel est censé être souple. Ne passez pas des semaines à obtenir les bons diagrammes. Dites-moi simplement ce qui se passe. Si vous le devez, utilisez une serviette.

Cela dit, je préfère les codeurs qui connaissent leur UML et leurs modèles de conception. Ils sont plus faciles à communiquer avec. Tant qu'ils savent que la production de diagrammes n'est pas un travail à temps plein.

Je demande s'il est logique d'utiliser des documents (non codés) qui modélisent le logiciel comme la principale source de vérité sur la conception de logiciels

Non, cela n'a jamais de sens. Votre code est votre principal document de conception, c'est-à-dire "la principale source de vérité sur la conception de logiciels". Seul le code décrit exactement ce que fait l'application, car le compilateur prend cette conception et crée l'application à partir de celle-ci.

Bien sûr, utilisez des diagrammes comme documents de conception supplémentaires, mais s'ils ne sont pas générés automatiquement à partir du code, méfiez-vous qu'ils racontent une histoire différente de la conception réelle. Si UML flotte votre bateau, utilisez-le. Sinon, utilisez autre chose.

Certaines personnes trouvent utile d'esquisser leur pensée sous forme de diagramme avant de commencer à écrire du code. Mais rappelez-vous ce que l'oncle Bob a dit à ce sujet:

" Donc, oui, les diagrammes peuvent parfois être inappropriés. Quand sont-ils inappropriés? Lorsque vous les créez sans code pour les valider, puis que vous avez l'intention de les suivre. Il n'y a rien de mal à dessiner un diagramme pour explorer une idée. "

Si vous utilisez UML pour explorer une conception, jetez-les lorsque vous commencez à coder. Écrivez un test, puis écrivez du code pour le faire passer. Répéter. De cette façon, vous vous retrouverez avec un design validé. UML ne peut jamais vous offrir le même niveau de validation de votre conception.

La plupart, sinon tous les informaticiens que je connais, pensent qu'il est avantageux de modéliser un logiciel avec UML ou d'autres types de diagrammes avant de coder.

Je ne suis pas en désaccord avec le fait que toutes les personnes que vous connaissez croient cela, mais je ne pense pas que ce soit nécessairement commun à tous les niveaux. En 1970, Winston Royce savait que le développement logiciel avait un certain niveau d'itération entre les activités de conception et de code. En 1992, Jack Reeves a écrit que le codage était la véritable activité de conception (également discutée sur le Wiki C2 ).

Cela ne signifie pas que les gens ont essayé de créer des outils de développement basés sur des modèles. Il existe des outils qui tentent de générer du code à partir de modèles UML (et pas seulement des diagrammes de classes, mais reliant différents types de diagrammes et générant du code à partir d'eux). Mais ce ne sont pas, du moins d'après ce que j'ai vu, des outils largement utilisés.

Cela ne signifie pas non plus que vous devez passer directement des exigences à l'écriture de code. Il y a certaines décisions de conception qui sont essentielles pour bien commencer tôt et un certain niveau de modélisation peut être utile pour s'assurer que tout le monde comprend les options, leur impact et peut communiquer. Certaines personnes (y compris moi-même) appellent cela "l'architecture logicielle" .

Le code ne ment pas. Il est vérifié par le compilateur ou l'interpréteur. Nous espérons qu'il a des tests automatisés et doit passer une analyse de code statique. Si un module ne s'interface pas correctement avec un autre module, cela est généralement évident dans le code car vous obtenez un message d'erreur.

C'est vraiment le cœur de certains des aspects de la modélisation agile, en particulier les spécifications exécutables et la source unique d'information . Je ne suis pas nécessairement d'accord avec TDD, mais l'idée d'avoir votre code et les tests associés (de l'unité aux tests d'acceptation, de préférence capturés comme des tests automatisés) soit la seule source de vérité est une bonne idée.

Même si les diagrammes eux-mêmes sont cohérents, vous ne pouvez pas être sûr que le code les implémente réellement. Oui, il existe des générateurs de code, mais ils ne génèrent jamais tout le code.

Je pense qu'en règle générale, passer du modèle-> code est la mauvaise façon. Au lieu de cela, le code doit générer des modèles. Autrement dit, les outils devraient être en mesure d'examiner le code et de générer des représentations graphiques et tabulaires qui peuvent être encore améliorées lorsque les ingénieurs écrivent du texte autour d'eux. Et cette génération de modèles à partir de code devrait faire partie intégrante d'un processus de génération et de publication.

Il existe des outils qui, à des degrés divers, le prennent en charge pour différentes langues. Étant donné la nature des langues et des paradigmes, c'est plus facile pour certains que pour d'autres.

J'ai énuméré quelques inconvénients de cette procédure qui me font me demander pourquoi tant de gens (selon mon expérience) la considèrent comme la meilleure façon de faire de la conception de logiciels.

Je ne pense pas que ces gens comprennent nécessairement le génie logiciel et la conception de logiciels. Je pense que ces gens examinent ce que font les autres disciplines de l'ingénierie et le mettent en correspondance avec des choses qu'ils pensent que les ingénieurs logiciels devraient faire. Mais ils ignorent une différence majeure. D'autres disciplines d'ingénierie créent d'abord des modèles et des simulations, car il est extrêmement coûteux et long de construire le produit réel. En génie logiciel, nous pouvons prendre des morceaux de notre conception et produire quelque chose qui est testable dans un environnement réel en très peu de temps et à très faible coût. L'économie est très différente.

Quels sont les avantages de la modélisation de systèmes logiciels par rapport à tout faire en code?

Lorsque vous avez un système logiciel extrêmement complexe, avoir des modèles signifie avoir quelque chose de plus facile à comprendre. C'est un niveau d'abstraction différent, quelque chose pour aider les gens à comprendre les différentes facettes de votre système. C'est l'une des raisons pour lesquelles il existe tant de langages de modélisation et de types de modèles différents autorisés par chaque langage ou notation de modélisation - pour permettre aux différentes parties prenantes de comprendre, conceptuellement, le système logiciel rapidement et facilement.

Je demande s'il est logique d'utiliser des documents (non codés) qui modélisent le logiciel comme la principale source de vérité sur la conception de logiciels. Je n'ai pas le cas en tête lorsqu'une partie importante du code est générée automatiquement à partir de ces documents. Si tel était le cas, je considérerais les documents eux-mêmes comme du code source et non comme un modèle.

De nombreux documents non codés sont utiles comme plans . Autrement dit, la «vérité» de la conception doit suivre cette direction. C'est une façon de modéliser des éléments qu'un design doit remplir. On pourrait les appeler des documents d'exigences, mais c'est peut-être trop fort dans tous les exemples que je pourrais donner. J'ai utilisé PlantUML via PlantText.com pour les produire.

• Les diagrammes de cas d'utilisation peuvent montrer les fonctionnalités et interactions prévues avec les utilisateurs ou les systèmes externes.

• Les diagrammes d'activité peuvent montrer les processus métier qu'un logiciel doit prendre en charge.

• Les diagrammes d'état peuvent montrer la dynamique voulue sur un site Web:

• Les modèles de conception de Gang of Four sont présentés comme des modèles statiques et dynamiques. Par exemple, Memento:
  
  

J'ai énuméré quelques inconvénients de cette procédure qui me font me demander pourquoi tant de gens (selon mon expérience) la considèrent comme la meilleure façon de faire de la conception de logiciels.

Si vous êtes intéressé par de vraies informations sur l'utilisation d'UML en dehors de votre expérience, il y a quelques études qui ont été faites (j'ai essayé de trouver des liens vers des articles non paywall):

• Petre, Marian (2013). UML en pratique . Dans: 35th International Conference on Software Engineering (ICSE 2013), 18-26 mai 2013, San Francisco, CA, USA, pp. 722–731.
• Mangano, TD LaToza, M. Petre et A. van der Hoek (2015). Comment les concepteurs de logiciels interagissent avec les esquisses sur le tableau blanc . Dans: IEEE Transactions on Software Engineering, vol. 41, non. 2, pp. 135-156.
• Andrew Forward et Timothy C. Lethbridge. 2008. Problèmes et opportunités pour le développement de logiciels centrés sur le modèle par rapport au code: une enquête auprès des professionnels du logiciel . Dans Actes de l'atelier international de 2008 sur les modèles en génie logiciel (MiSE '08). ACM, New York, NY, USA, 27-32.

Nous, les développeurs, aimons utiliser des images pour expliquer notre monde, alors voici un avec la production d'une voiture:

• La voiture est le résultat de la chaîne de production, idem pour le code (ajoutez bien sûr le processus de déploiement).
• Le document de conception de la voiture est le même que le document de conception du logiciel.

Dans nos mondes, il arrive souvent que ceux qui conçoivent et fabriquent le document de conception soient les mêmes que celui qui produit le code. Ce n'est pas vrai dans les autres domaines. Cependant, cela ne signifie pas que vous pouvez vraiment obtenir le même niveau de qualité en les faisant tous ensemble.

En créant ces documents d'abord sans codage (à l'exclusion de tout ce qui ressemble à une preuve de concept pour la faisabilité, ...):

• Vous êtes sûr de réfléchir avant de faire, le codage une fois que vous savez ce que vous avez à faire est FACILE.
• Vous êtes en mesure de concentrer les gens plus expérimentés sur la partie la plus difficile de votre logiciel: conception, algorithme / mathématiques est tout sauf dans un but très spécifique (embarqué, temps réel, assemblage).
• Vous pouvez déléguer à des personnes moins expérimentées une bonne partie du processus de codage tandis que les personnes plus expérimentées se concentrent uniquement sur la partie la plus critique qui a besoin du niveau de leurs compétences. Ces personnes moins expérimentées en apprendront beaucoup à ce sujet.
• Vous pouvez discuter avec des non-informaticiens à travers l'image de votre document de conception, alors que si vous n'aviez que du code, vous auriez à extraire une image de ce que vous avez fait, avec tout le risque d'oublier quelque chose (un auditeur oublié quelque part ...). Voir la réponse de CandiedOrange pour plus d'aspects sur la communication.
• Lorsque vous devez faire évoluer votre logiciel, vous pouvez mieux anticiper quel sera l'impact.
• La conception rendra facile la découpe de votre logiciel et le développement simultané de ce dernier.
• Écrire ces fichus tests unitaires réverbatifs sera beaucoup plus facile lorsque vous n'aurez pas à vous soucier d'avoir à couvrir tous les cas tout en les codant, dans une approche TDD codant le test avant que le code ne soit facile.
• ...

Remarque: ces affirmations supposent que le code est vraiment le reflet de la conception et qu'elles sont toutes les deux à jour ...