Comment les programmes clojure/lisp sont-ils modélisés sous forme de diagramme ?

Question

J'ai essayé de caler mes diagrammes clojure dans ce qui est disponible en UML, en utilisant des blocs de classe comme espaces de noms au niveau des fichiers et des liens de dépendance pour montrer les relations, mais c'est maladroit et tend à décourager les modèles fonctionnels. J'ai également essayé de développer des solutions ad-hoc, mais je n'arrive pas à découvrir une solution qui fonctionne aussi bien qu'UML avec, disons, Java (de simples graphes dirigés semblent fonctionner de manière vague, mais les résultats ne sont pas assez détaillés). De plus, je ne trouve rien sur le web à ce sujet.

Pour être clair, je n'essaie pas de faire quoi que ce soit de fantaisiste comme la génération de code ; je parle simplement de diagrammes papier-crayon, principalement pour mon propre bénéfice. Je suppose que je ne suis pas la première personne à avoir envisagé cela pour un langage lisp.

Quelles solutions ont été proposées ? Existe-t-il des normes communément utilisées ? Quelles sont vos recommandations ? Quels outils utilisez-vous ?

Answer 1

Cela dépend de ce que vous voulez décrire dans votre programme.

Dépendances

Utilisez les diagrammes de classes pour modéliser les dépendances entre les espaces de noms ; dans ce cas, il est plus clair d'utiliser les packages au lieu des classes dans un diagramme.

Vous pouvez également utiliser les diagrammes de classes pour modéliser les dépendances entre les acteurs.

Flux de données

Vous pouvez également utiliser Diagrammes de communication pour modéliser le flux de données dans votre programme. Dans ce cas, représentez chaque espace de noms comme une entité et chaque fonction comme une méthode de cette entité.

Ou, dans le cas des acteurs, représentez chaque acteur comme une entité et chaque message comme une méthode.

De toute façon, il n'est pas utile d'essayer de décrire la algorithme de votre programme en UML. D'après mon expérience, ils sont mieux décrits dans les commentaires du fichier source.

Answer 2

Je pense qu'il s'agit moins du langage que de votre modèle conceptuel. Si vous adoptez une approche de "traitement en flux", un diagramme de réseau de flux de données pourrait être la bonne approche, comme dans certains des projets de la Commission européenne. Diagrammes de schémas dans SICP . Si vous adoptez une approche plus orientée objet (qui est bien prise en charge par Lisp), les diagrammes d'activité UML peuvent être plus pertinents.

Answer 3

Eh bien, UML est profondément ancré dans la conception OO (avec C++ !), il sera donc très difficile de faire correspondre une approche fonctionnelle avec UML. Je ne connais pas très bien Clojure, mais il est possible de représenter les éléments qui ressemblent aux classes et interfaces Java (protocoles ?), mais pour tous les autres, ce sera vraiment difficile. La FP ressemble plus à une série de transformations de l'entrée vers la sortie, il n'y a pas de diagramme UML clair pour cela (peut-être des diagrammes d'activité ?). Les diagrammes les plus courants concernent la structure statique et l'interaction entre les objets, mais ils ne sont pas vraiment utiles pour le paradigme FP. En fonction de votre objectif, les diagrammes de composants et de déploiement peuvent être applicables.

Answer 4

Je pense personnellement qu'il faut modéliser le le flux des données et non la structure du code parce que, d'après ce que j'ai vu des grands projets Clojure (pas vraiment si grands), la disposition du code a tendance à être vraiment ennuyeuse, avec un énorme tas de utilitaires composables et une classe qui les associe avec des transactions map, redure et STM.

Clojure est très flexible dans le modèle que vous choisissez et vous pouvez donc vouloir aller dans l'autre sens. Faites d'abord le diagramme puis choisissez les parties et les modèles du langage qui expriment proprement le modèle que vous avez construit.

Answer 5

Je ne pense pas que quelque chose comme UML conviendrait à Clojure - UML est plutôt axé sur le paradigme orienté objet qui est généralement déconseillé dans Clojure.

Quand je fais de la programmation fonctionnelle, j'ai tendance à penser beaucoup plus en termes de données et fonctions :

• De quelles structures de données ai-je besoin ? En Clojure, cela se résume généralement à définir une structure map pour chaque entité importante que je traite. A simple liste de champs est souvent suffisante dans les cas simples. Dans des cas plus complexes avec de nombreuses entités différentes, vous voudrez probablement dessiner un arbre montrer la structure de vos données (où chaque nœud de l'arbre représente un type de carte ou d'enregistrement)
• Comment ces structures de données passent-elles par différentes fonctions de transformation pour obtenir le bon résultat ? Idéalement, il s'agit de fonctions pures qui prennent une valeur immuable en entrée et produisent une valeur immuable en sortie. En général, je les esquisse sous la forme d'un pipeline / organigramme .

Si vous avez suffisamment bien réfléchi à ce qui précède, la conversion en code Clojure est assez facile.

1. Définissez une ou plusieurs fonctions constructrices pour vos structures de données, et écrivez quelques tests pour prouver qu'elles fonctionnent.
2. Écrire les fonctions de transformation de bas en haut (c'est-à-dire faire fonctionner et tester les opérations les plus basiques d'abord, puis les composer ensemble pour définir les fonctions plus importantes). Écrivez des tests pour chaque fonction.
3. Si vous avez besoin de fonctions utilitaires pour l'interface graphique ou l'entrée-sortie, etc., écrivez-les à la demande, au fur et à mesure qu'elles sont nécessaires.
4. Collez le tout ensemble, en testant au REPL pour vous assurer que tout fonctionne.

Notez que vos fichiers sources seront généralement aussi structurés dans l'ordre indiqué ci-dessus, avec les fonctions les plus élémentaires en haut et les fonctions composées de plus haut niveau vers le bas. Vous ne devriez pas avoir besoin de dépendances circulaires (c'est une mauvaise odeur de conception en Clojure). Les tests sont essentiels - à mon avis, beaucoup plus importants dans un langage dynamique comme Clojure que dans un langage OOP à typage statique.

La logique globale de mon code se trouve généralement dans les dernières lignes de mon fichier de code source principal.