UML peut-il être utilisé pour modéliser un programme fonctionnel?

Plus précisément, comment modélisez-vous un programme fonctionnel ou développé à l’aide du style fonctionnel (sans classes) à l’aide d’un diagramme et non d’une représentation textuelle? Est-ce possible? Quelqu’un pourrait-il me diriger vers l’application la plus proche? (open source, gratuit comme dans la bière, s’il vous plait)

Les programmeurs fonctionnels ne sont généralement pas très utiles pour les diagrammes. De nombreux programmeurs fonctionnels (mais pas tous) trouvent que l’écriture des types est un bon moyen d’encapsuler les relations de conception que les programmeurs OO mettent dans les diagrammes UML.

Etant donné que l’état mutable est rare dans les programmes fonctionnels, il n’y a pas “d’objects” mutables, il n’est donc généralement pas utile ou nécessaire de représenter les relations entre eux. Et bien qu’une fonction puisse en appeler une autre, cette propriété n’est généralement pas importante pour la conception globale d’un système, mais uniquement pour l’implémentation de la fonction effectuant l’appel.

Si je ressentais un fort besoin de schématiser un programme fonctionnel, je pourrais utiliser une carte conceptuelle dans laquelle les types ou fonctions jouent le rôle de concepts.

UML n’est pas seulement des diagrammes de classes, vous savez?

La plupart des autres types de diagrammes (diagrammes de cas d’utilisation, diagrammes d’activité, diagrammes de séquence …) sont parfaitement applicables à un style de programmation purement fonctionnel. Même les diagrammes de classes peuvent toujours être utiles si vous n’utilisez simplement pas les atsortingbuts et les associations et interprétez “class” comme “collection de fonctions associées”.

UML est un recueil de différents types de modélisation. Si vous parlez du diagramme d’objects (diagramme de classes), vous ne trouverez rien qui corresponde à votre utilisation souhaitée. Mais si vous parlez d’un diagramme d’interaction (diagramme d’activité) ou d’un diagramme de besoins (diagramme de cas d’utilisation), ils vous aideront bien sûr et feront partie de la base UML.

Les programmeurs fonctionnels ont leur propre version de UML, elle s’appelle Category Theory .

(Il y a une certaine vérité à cela, mais il est destiné à être lu avec une touche d’ humour ).

Pour modéliser un programme fonctionnel, en utilisant un diagramme et non une représentation textuelle, vous pouvez utiliser la notation comme celle utilisée pour programmer dans Viskell ou Luna.

entrer la description de l'image ici

Je suppose que vous pourriez créer une classe appelée noclass et mettre des fonctions en tant que méthodes. En outre, vous pouvez diviser noclass en plusieurs catégories de fonctions.

Je n’ai pas vraiment essayé de modéliser un grand système en UML et de passer ensuite à une implémentation fonctionnelle, mais je ne vois pas pourquoi cela ne devrait pas fonctionner.

En supposant que l’implémentation allait être Haskell, je commencerais par définir les types et leurs relations à l’aide d’un diagramme de classes. Atsortingbuez des fonctions aux classes par leur argument principal, mais gardez à l’esprit qu’il s’agit simplement d’un artefact d’UML. Si c’était plus simple de créer un object singleton fictif juste pour contenir toutes les fonctions, ce serait bien aussi. Si l’application nécessite un état, je n’aurais aucun problème à la modéliser dans un diagramme d’état ou un diagramme de séquence. Si j’avais besoin d’une monade personnalisée pour la sémantique de séquençage spécifique à l’application, cela pourrait devenir un stéréotype. le but serait de décrire ce que l’application fait en termes de domaine.

Le point principal est que UML pourrait être utilisé pour modéliser un programme pour une implémentation fonctionnelle. Vous devez garder à l’esprit un mappage à l’implémentation (et cela ne nuirait pas à le documenter), et l’ajustement est loin d’être exact. Mais cela pourrait être fait et cela pourrait même append de la valeur.

Je me rends compte que c’est un vieux fil mais je ne comprends pas le problème ici.

Une classe n’est qu’une abstraction d’un concept qui associe la fonctionnalité de ses méthodes d’une manière plus humaine. Par exemple, la classe WaveGenerator peut inclure les méthodes Sine, Sawtooth et SquareWave. Les trois méthodes sont clairement liées à la classe Generator. Cependant, tous les trois sont également apasortingdes. Si elles sont conçues correctement, elles n’ont pas besoin de stocker des informations d’état en dehors de la méthode. Cela en fait des objects sans état qui, si je comprends bien, en font des fonctions immuables qui constituent un concept fondamental du paradigme fonctionnel.

D’un sharepoint vue conceptuel, je ne vois aucune différence entre

laissez Enveloppe Sine = …

et

laisser Envelope Generator.Sine = …

autre que le fait que ce dernier pourrait donner une meilleure idée de l’object de la fonction.