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

20

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.

Frank Puffer
la source
5
Je pense que c'est une question tout à fait valable. Si notre modèle a une valeur, il doit correspondre au code. Alors pourquoi ne pas concevoir le modèle dans le même langage que nous utiliserons plus tard pour l'implémenter? Ensuite, ils sont toujours synchronisés. Et si vous préférez des graphiques sophistiqués, ils peuvent être générés à partir du code.
Ralf Kleberhoff
3
Vous devriez alors connaître davantage de personnes "IT". Ou peut-être devrais-je dire que vous devriez vous familiariser avec plus de communautés au sein de ce parapluie.
Derek Elkins a quitté le SE
@DocBrown: Bien que les réponses à cette question et en particulier les articles liés dans votre commentaire fournissent des informations pertinentes, la question d'origine est très différente.
Frank Puffer
@FrankPuffer: J'en suis conscient, j'ai voté pour la réouverture. Néanmoins, je pense que le cœur de votre question - "qu'est-ce que la conception de logiciels" et "le rôle de la modélisation dans la conception de logiciels", est une question très large, peut-être trop large pour y répondre de manière sensée.
Doc Brown

Réponses:

23

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.

candied_orange
la source
2
"il n'y a tout simplement pas de code à ce niveau d'abstraction qui tient sur un tableau blanc" Cela soulève une question intéressante. Pourquoi pas? Qu'est-ce qui devrait être vrai pour que le point d'entrée d'un système explique à un très haut niveau ce qu'il fait?
RubberDuck
2
Parce que le code doit être tout pour tout le monde (et au moins un compilateur). Un modèle peut avoir un public ciblé.
candied_orange
Je pense qu'il est malheureux d'utiliser le mot «formalisme» pour cela. Soit il gonfle excessivement ce que font les "modélisateurs", soit il dégrade la modélisation formelle réelle . (Il ne semble pas non plus vraiment capturer votre intention de ce que je peux dire ici. Votre préoccupation ne semble pas concerner la modélisation elle-même, mais l'utiliser comme porte d'entrée ou pour des raisons bureaucratiques même quand elle n'ajoute pas de valeur.)
Derek Elkins a quitté le SE
3
Mon problème n'est pas avec la modélisation. C'est en utilisant des cérémonies formelles en remplacement de la pensée critique. J'essaie de dire qu'une grande partie du dénigrement du modèle se produit parce qu'une grande partie de la modélisation est tombée dans cette foule. La modélisation peut être très bonne. Mais il a un côté sombre.
candied_orange
1
"Je peux adapter le modèle sur un tableau blanc" est une façon très concrète (excellente!) De dire "Je peux faire une abstraction de quelque chose de plus compliqué pour aider à comprendre ou à communiquer l'aspect que je considère important." C'est ce que fait une bonne modélisation en général, que ce soit un logiciel ou autre chose complexe.
Fuhrmanator
6

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.

David Arno
la source
Un contre-exemple (?) :: la séparation de la vue du modèle (ou n'importe quel motif GoF) peut être facilement dessiné comme une vérité voulue de la conception (plan) proposée par un architecte. Les développeurs qui s'écartent de cette intention ne rendent pas inutile le modèle (prévu). Oui, le code est la "vérité" mais ce n'est pas nécessairement le design. La validation ne doit pas être automatique avec UML ou un modèle. Le fait qu'il ne l'est pas ne rend pas un modèle digne des déchets.
Fuhrmanator
Quant aux tests, je ne suis pas sûr qu'il soit utile de valider un design. Pouvez-vous écrire des tests qui montrent que la logique du domaine n'est pas dans la couche de présentation (un problème très courant avec les implémentations qui s'écartent d'une conception prévue)? Montrer un diagramme des couches à un développeur et expliquer qu'une actionPerformed()méthode se trouve dans la couche de présentation, et qu'elle devrait simplement passer le contrôle à la couche de domaine, est un aspect clé de la séparation. (Exemple trivial, mais il peut être appliqué à toutes sortes de stratégies de conception qui ne sont pas faciles à afficher uniquement dans le code).
Fuhrmanator
5

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.

Thomas Owens
la source
5

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. entrez la description de l'image ici

  • Les diagrammes d'activité peuvent montrer les processus métier qu'un logiciel doit prendre en charge. entrez la description de l'image ici

  • Les diagrammes d'état peuvent montrer la dynamique voulue sur un site Web: entrez la description de l'image ici

  • Les modèles de conception de Gang of Four sont présentés comme des modèles statiques et dynamiques. Par exemple, Memento:
    entrez la description de l'image ici
    entrez la description de l'image ici

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):

Fuhrmanator
la source
0

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 ...

Walfrat
la source
Cette réponse décrit un scénario proche du meilleur des cas. Vous mentionnez une mise en garde à la fin qui est assez importante en soi. Il y en a bien d' autres. Vous pouvez facilement omettre les aspects nécessaires, sous-estimer la complexité d'une partie, ne pas prendre en compte les contraintes imposées par les bibliothèques / frameworks que vous utilisez, ne pas prendre en compte les bogues dans les dépendances, ne pas prendre en compte les performances ou d'autres exigences non fonctionnelles, sur l' ingénieur, ne pas anticiper les changements, ou tout simplement ne pas être si bon en conception. Il est peu probable que ce meilleur scénario se réalise, même approximativement dans un contexte professionnel.
Derek Elkins a quitté SE
Si vous commencez par ne considérer que chaque mise en garde de tout, vous n'irez nulle part. Quelle que soit la méthode que vous utilisez. Et une longue liste de ce que vous avez dit est parfaitement valable lorsque vous ne faites que du code.
Walfrat