Est-ce que UML peut être utilisé pour modéliser un programme fonctionnel?
Plus précisément, comment modélisez-vous un programme fonctionnel, ou un programme développé avec le style fonctionnel (sans classes) à l'aide d'un diagramme, et non d'une représentation textuelle, est-il possible et pourrait-il m'indiquer quelqu'un qui pourrait m'indiquer directement (open source, gratuit comme dans la bière, s'il vous plait)
Les programmeurs fonctionnels n’ont généralement pas beaucoup d’utilisation pour les diagrammes. De nombreux programmeurs fonctionnels (mais pas tous) estiment que l'écriture de 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 '"objets" mutables, il n'est donc généralement ni utile ni nécessaire de schématiser 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 la mise en œuvre de la fonction effectuant l'appel.
Si je ressentais un fort besoin de schématiser un programme fonctionnel, je pourrais utiliser un carte conceptuelle dans lequel les types ou les 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, etc.) conviennent parfaitement à un style de programmation purement fonctionnel. Même les diagrammes de classes peuvent toujours être utiles, si vous n'utilisez tout simplement pas d'attributs et d'associations et n'interprétez "classe" comme "collection de fonctions connexes".
UML est un condensé de différents types de modélisation. Si vous parlez du diagramme d'objets (diagramme de classes), vous ne trouverez rien qui convienne à votre utilisation souhaitée. Mais si vous parlez d'un diagramme d'interaction (diagramme d'activité) ou d'exigences (diagramme de cas d'utilisation), ils vous aideront évidemment et font partie de la base UML.
Les programmeurs fonctionnels ont leur propre version de UML, elle s'appelle Théorie des catégories .
(Il y a une certaine vérité à cela, mais cela doit être lu avec une touche de humour ).
UML est une approche objet car au niveau graphique, vous ne pouvez pas définir de modélisation fonctionnelle. Une astuce consiste à ajouter directement des contraintes et des notes au modèle et non au niveau du diagramme. Je veux dire que vous pouvez écrire une documentation fonctionnelle complète sur chaque élément de modèle directement dans le métamodèle et afficher uniquement une vue d'objet à l'aide de l'éditeur UML. C’est peut-être stupide mais j’ai trouvé cette démo en français exactement sur le même sujet et en utilisant EclipseUML Omondo: OCL et UML 2.2 (démo en français 3mn): http: // www.download-omondo.com/regle_ocl.swf
Cette démonstration explique comment ajouter des contraintes directement sur les méthodes au niveau du métamodèle. L’intérêt de cette démonstration est que l’utilisation d’un modèle unique pour l’ensemble du projet permet d’être suffisamment souple pour étendre le langage UML traditionnel et éviter les modèles supplémentaires SysML, BPMN, DSL car toutes les informations sont construites sur le métamodèle UML 2.2. Je ne sais pas si ce sera un succès, mais cette initiative est très intéressante car elle réduit la complexité de la modélisation et ouvre de nouvelles frontières!
Je suppose que vous pourriez créer une classe appelée noclass et y placer des fonctions en tant que méthodes. En outre, vous pouvez scinder la variable noclass en plusieurs catégories de fonctions.
Je réalise que c'est un vieux fil, mais je ne comprends pas le problème ici.
Une classe est simplement une abstraction d'un concept qui lie la fonctionnalité de ses méthodes de manière plus conviviale. 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, les trois sont également apatrides. S'ils sont conçus correctement, ils n'ont pas besoin de stocker les informations d'état en dehors de la méthode. Cela en fait des objets sans état qui - si je comprends bien - en font des fonctions immuables qui constituent un concept fondamental du paradigme fonctionnel.
D'un point de vue conceptuel, je ne vois aucune différence entre
let Envelope Sine = ...
et
let Envelope Generator.Sine = ...
autre que le fait que ce dernier puisse donner un meilleur aperçu de l’objectif de la fonction.
Je n'ai pas réellement essayé de modéliser un grand système en UML, puis de passer à une implémentation fonctionnelle, mais je ne vois pas pourquoi cela ne fonctionnerait pas.
En supposant que l'implémentation soit Haskell, je commencerais par définir les types et leurs relations à l'aide d'un diagramme de classes. Attribuez des fonctions aux classes en fonction de leur argument principal, mais gardez à l'esprit qu'il ne s'agit que d'un artefact de UML. S'il était plus facile de créer un objet singleton fictif uniquement pour contenir toutes les fonctions, cela conviendrait également. Si l'application a besoin d'un état, la modélisation dans un diagramme d'états ou un diagramme de séquence ne me pose aucun problème. Si j'avais besoin d'une monade personnalisée pour la sémantique de séquençage spécifique à une application, cela pourrait devenir un stéréotype; l'objectif serait de décrire ce que l'application fait en termes de domaine.
Le point principal est que UML pourrait pourrait être utilisé pour modéliser un programme pour une implémentation fonctionnelle. Vous devez garder à l'esprit un mappage de la mise en œuvre (et cela ne ferait pas de mal de le documenter), et l'ajustement est loin d'être exact. Mais cela pourrait être fait, et cela pourrait même ajouter de la valeur.