Qu'est-ce que les programmeurs fonctionnels utilisent à la place d'UML?
Je suis étudiant CS. J'assiste actuellement à des conférences, où nous apprenons l'analyse et la conception objectives. Il consiste principalement à écrire des cas d'utilisation, à analyser le problème que nous pouvons rencontrer lors de l'écriture d'une application pour le client, et à concevoir le projet de manière à ce qu'il soit à la fois extensible, clair pour les développeurs et ne génère pas de problèmes lorsque le client se dispute sur certains traits. Puisqu'il est "objectif", nous l'apprenons du point de vue OOP (classes et autres).
Maintenant, nous utilisons UML comme outil d'aide. Je crois que j'ai une bonne compréhension de la POO, mais j'ai également appris le paradigme fonctionnel et l'ai utilisé avec succès dans certains de mes petits projets.
Notre professeur, face à "qu'en est-il du paradigme fonctionnel?" question, a répondu qu'il ne programmait pas de projet plus important dans des langages fonctionnels, et il ne sait pas quel outil les programmes fonctionnels peuvent utiliser.
Alors, qu'est-ce qu'ils utiliseraient? Existe-t-il une méthodologie pour cela? Ou peut-être qu'il n'y a pas besoin d'une telle chose?
Je ne peux pas parler pour tous les programmeurs fonctionnels, mais ceux que je connais commencent tous par écrire les signatures de type des fonctions de niveau supérieur, puis comme ils ont besoin de plus de détails, ils écrivent les signatures de type des fonctions d'assistance, etc.
Cela fonctionne en raison du manque d'effets secondaires dans la programmation fonctionnelle, donc les fonctions sont toutes spécifiées en termes uniquement de leurs entrées et sorties. Cela rend leurs signatures de type beaucoup plus utiles comme outil de conception que dans la programmation impérative. C'est une des raisons pour lesquelles vous les voyez utilisées même lorsque le compilateur peut les déduire.
En ce qui concerne les outils de création de diagrammes, avec tout le respect que je dois à votre professeur, je ne les ai pas utilisés de manière significative dans le paradigme any depuis que j'ai quitté l'école.
La norme UML définit plus d'une douzaine de types de diagrammes différents, comme indiqué dans ce tableau pratique:
Source: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg
Voir aussi Figure A.5 La taxonomie des diagrammes de structure et de comportement dans la spécification UML 2.5.
Notez qu'il s'agit d'un exemple de diagramme de classe, avec des relations de sous-typage is-a entre les types de diagramme et les types de diagramme abstraits en italique. Bien que ces types de diagramme soient en fait des classes dans le métamodèle UML, ce diagramme de classe est toujours utile pour illustrer une hiérarchie, sans aucune connexion à la POO.
Il existe quelques types qui ne s'appliquent clairement qu'à la POO, par exemple le diagramme de classes ou le diagramme d'objets . Mais le reste est plus largement applicable que juste pour les systèmes orientés objet.
Diagrammes de machines à états - FP n'évite pas les états, il les rend simplement explicites. Un diagramme de machines à états peut être utile pour expliquer le flux de contrôle, ou les différentes transitions d'état dans le programme.
Les diagrammes d'activité - sont utiles dans des cas similaires à ceux du diagramme de la machine d'état, mais à un niveau supérieur. Ils peuvent être utilisés pour expliquer le flux de données entre différents sous-systèmes ou pour modéliser des processus métier externes.
Diagrammes d'interaction - modélisez les interactions entre plusieurs processus avec état. De toute évidence, cela n'est pas utile pour modéliser les internes d'un programme fonctionnel pur. Cependant, UML ne consiste pas seulement à modéliser la structure du code, mais principalement à fournir un langage de modélisation universel. Avec un diagramme d'interaction, je pourrais par exemple utiliser des diagrammes d'interaction pour modéliser le comportement externe entre les systèmes, par ex. entre un navigateur et un serveur Web - même lorsqu'ils sont écrits à l'aide des techniques FP.
Diagrammes de cas d'utilisation - Les cas d'utilisation et les exigences sont indépendants de la technologie utilisée pour les satisfaire. OOP ou FP est absolument hors de propos ici.
Diagrammes de déploiement - Ce type de diagramme est utilisé pour décrire la relation entre les logiciels exécutables et les ressources matérielles. Que ce logiciel ait été écrit dans une langue FP n'a pas d'importance.
Diagrammes des composants - De nos jours, la plupart des langages fonctionnels prennent explicitement en charge la programmation modulaire. Un diagramme de composants décrit les composants/modules et leurs interfaces proposées et requises. Cela me rappelle beaucoup de modules Functor d'OCaml.
Diagrammes de profil - décrivent les extensions d'UML lui-même et ne sont jamais utilisées en tant que telles.
Diagrammes de structure composite - décrivent la structure des composites. Il peut être utilisé pour décrire des structures de données, voire les points d'interaction d'une fonction. Wikipedia montre un schéma de la fonction de Fibonacci comme exemple:
![Composite Structure Diagram for a Fibonacci funciton]()
Source: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png
Dans un sens, ce serait le choix des programmeurs fonctionnels plutôt qu'un diagramme de classes, mais cela semble horriblement surdimensionné….
Diagrammes de packages - Les packages sont l'équivalent UML des espaces de noms. Ce type de diagramme fait plus partie de l'infrastructure du langage UML qu'un type de diagramme distinct. Par exemple, vous pouvez utiliser des packages pour classer un grand diagramme de cas d'utilisation.
Ainsi, comme nous l'avons vu, divers types de diagrammes UML peuvent toujours être utiles lors de la programmation fonctionnelle.
J'ai rarement ressenti le désir d'utiliser UML lors de la conception d'un système, et d'utiliser principalement UML pour faire mes devoirs assignés, ou pour communiquer le contour d'une architecture avec un croquis rapide. Même pour un système OOP, UML ne fournit pas assez de valeur pour l'utiliser tout le temps - le code réel en dit plus que mille diagrammes. Je pourrais imaginer utiliser des diagrammes de type UML pour expliquer les dépendances entre diverses fonctions et structures de données dans un programme FP, mais pas encore - mon style personnel préfère un mélange de OOP et FP où FP sont utilisées à l'échelle locale, mais n'influencent pas l'architecture globale.