Existe-t-il un langage ou un style de modélisation visuelle pour le paradigme de functional programming?

UML est un standard destiné à la modélisation de logiciels qui seront écrits en langage OO, et va de pair avec Java. Cependant, pourrait-il être utilisé pour modéliser un logiciel destiné à être écrit dans le paradigme de functional programming? Quels diagrammes seraient rendus utiles compte tenu des éléments visuels incorporés?

Existe-t-il un langage de modélisation destiné à la functional programming, plus spécifiquement Haskell? Quels outils pour assembler des diagrammes recommanderiez-vous?

Édité par OP le 02 septembre 2009:

Ce que je recherche est la représentation la plus visuelle et la plus légère de ce qui se passe dans le code. Des diagrammes faciles à suivre, des modèles visuels pas nécessairement destinés à d’autres programmeurs. Je développerai très prochainement un jeu dans Haskell, mais comme ce projet concerne mon travail de fin d’études, je dois introduire une sorte de formalisation de la solution proposée. Je me demandais s’il y avait un équivalent au standard UML + Java, mais pour Haskell. Dois-je simplement m’en tenir aux story-boards, aux descriptions écrites, aux diagrammes non-formalisés (certaines images peu profondes ressemblant à des organigrammes), aux descriptions de cas d’utilisation non formalisées?

Edité par Jcolebrand le 21 juin 2012:

Notez que le demandeur voulait à l’origine un métphor visuel, et maintenant que nous avons trois ans, nous recherchons des outils plus / mieux. Aucune des réponses originales n’a vraiment abordé le concept d ‘«outil de conception de métaphore visuelle», alors … c’est ce que la nouvelle prime cherche à fournir.

    Nous utilisons des démonstrateurs de théorèmes pour réaliser des modélisations formelles (avec vérification), comme Isabelle ou Coq. Parfois, nous utilisons des langages spécifiques à un domaine (par exemple Cryptol) pour effectuer la conception de haut niveau, avant de dériver l’implémentation Haskell de “bas niveau”.

    Souvent, nous utilisons simplement Haskell comme langage de modélisation et en déduisons l’implémentation réelle via la réécriture.

    Les propriétés QuickCheck jouent également un rôle dans le document de conception, ainsi que les décompositions de type et de module.

    Je crois que le langage de modélisation pour Haskell s’appelle ” math “. Il est souvent enseigné dans les écoles.

    Oui, il existe des langages / techniques de modélisation / spécification largement utilisés pour Haskell. Ils ne sont pas visuels

    Dans Haskell, les types donnent une spécification partielle . Parfois, cette spécification détermine pleinement le sens / résultat tout en laissant divers choix de mise en œuvre. Aller au-delà de Haskell vers des langages avec des types dépendants, comme dans Agda et Coq (entre autres), les types sont beaucoup plus souvent utiles en tant que spécification complète .

    Lorsque les types ne suffisent pas, ajoutez des spécifications formelles, qui prennent souvent une forme fonctionnelle simple. (D’où, je crois, les réponses que le langage de modélisation de choix pour Haskell est Haskell lui-même ou “math”). Dans une telle forme, vous donnez une définition fonctionnelle optimisée pour plus de clarté et de simplicité. La définition peut même impliquer des opérations non calculables telles que l’égalité des fonctions sur des domaines infinis. Puis, étape par étape, vous transformez la spécification en un programme fonctionnel efficace. Chaque étape préserve la sémantique (dénotation), de sorte que la forme finale (“implémentation”) est garantie sémantiquement équivalente à la forme originale (“spécification”). Vous verrez ce processus appelé par divers noms, y compris “transformation de programme”, “dérivation de programme” et “calcul de programme”.

    Les étapes d’une dérivation typique sont principalement des applications du «raisonnement équationnel», complétées par quelques applications de l’induction mathématique (et de la co-induction). Etre capable d’exécuter un raisonnement aussi simple et utile était une motivation première pour les langages de programmation fonctionnels et ils doivent leur validité à la nature “dénotative” de la “programmation véritablement fonctionnelle”. (Les termes “dénotatif” et “véritablement fonctionnel” sont tirés de l’article séminal de Peter Landin intitulé The Next 700 Programming langages .) Le cri de ralliement pour la functional programming pure était alors “bon pour le raisonnement équationnel”. presque aussi souvent ces jours-ci. Dans Haskell, le dénotatif correspond aux types autres que les IOIO et les types reposant sur les IO (tels que STM ). Alors que les types dénotatifs / non- IO sont bons pour un raisonnement équationnel correct, les types IO / non-dénotatifs sont conçus pour être mauvais pour un raisonnement équationnel incorrect.

    Une version spécifique de dérivation-de-spécification que j’utilise aussi souvent que possible dans mon travail de Haskell est ce que j’appelle des “morphismes de classe de type sémantique” (TCM). L’idée est de donner une sémantique / interprétation pour un type de données, puis d’utiliser le principe TCM pour déterminer (souvent de manière unique) la signification de la plupart ou de toutes les fonctionnalités du type via les instances de classe de type. Par exemple, je dis que la signification d’un type d’ Image est une fonction de l’espace 2D. Le principe TCM me dit alors la signification des Functor , Functor , Applicative , Monad , Contrafunctor et Comonad , correspondant à ces instances pour les fonctions. C’est beaucoup de fonctionnalités utiles sur les images avec des spécifications très succinctes et convaincantes! (La spécification est la fonction sémantique plus une liste de classes de type standard pour lesquelles le principe sémantique TCM doit être respecté.) Et pourtant, je dispose d’une grande liberté pour représenter les images, et le principe TCM sémantique élimine les fuites d’abstraction. Si vous êtes curieux de voir des exemples de ce principe en action, consultez le document Conception de dénotation avec des morphismes de classe de type .

    Oui, Haskell.

    J’ai l’impression que les programmeurs utilisant des langages fonctionnels ne ressentent pas le besoin de simplifier leur langage de prédilection lorsqu’ils réfléchissent à leur conception, ce qui est une façon (plutôt désinvolte) de voir ce que UML fait pour vous.

    J’ai regardé quelques interviews vidéo et lu des interviews avec des artistes tels que erik meijer et simon peyton-jones. Il semble que lorsqu’il s’agit de modéliser et de comprendre les domaines problématiques, ils utilisent des signatures de type, en particulier des signatures de fonction.

    Les diagrammes de séquence (UML) peuvent être liés à la composition des fonctions. Un diagramme de classes statique (UML) peut être associé à des signatures de type.

    Dans Haskell, vous modélisez par types.

    Commencez simplement par écrire vos signatures de fonctions, de classes et de données sans aucune implémentation et essayez de les adapter. La prochaine étape est QuickCheck.

    Par exemple pour modéliser un sorting:

     class Ord a where compare :: a -> a -> Ordering sort :: Ord a => [a] -> [a] sort = undefined 

    puis teste

     prop_preservesLength l = (length l) == (length $ sort l) ... 

    et enfin la mise en oeuvre …

    Bien que ce ne soit pas une recommandation à utiliser (car il ne semble pas être disponible pour le téléchargement), le système HOPS visualise des graphiques de termes, qui représentent souvent une représentation pratique des programmes fonctionnels.

    Capture d'écran de HOPS

    Il peut également être considéré comme un outil de conception car il prend en charge la documentation des programmes ainsi que leur construction; Je crois que cela peut aussi vous aider à réécrire les termes si vous le voulez pour que vous puissiez les voir se dérouler .

    Malheureusement, je pense qu’elle n’est plus activement développée.

    Je me rends compte que je suis en retard à la fête, mais je donnerai toujours ma réponse au cas où quelqu’un le trouverait utile.

    Je pense que j’irais pour les méthodologies systémiques de SADT / IDEF0.

    Ces diagrammes peuvent être réalisés avec le programme Dia disponible sur Linux, Windows et MacOS.

    Quel serait l’intérêt de modéliser Haskell avec Maths? Je pensais que tout le but de Haskell était que cela se rapportait si étroitement aux maths que les mathématiciens pouvaient le prendre en main. Pourquoi voudriez-vous traduire une langue en elle-même?

    Lorsque vous travaillez avec un autre langage de programmation fonctionnel (f #), j’ai utilisé des diagrammes sur un tableau blanc décrivant les gros blocs, puis modélisé le système d’une manière OO en utilisant UML, en utilisant des classes. Il y a eu un léger manque de correspondance dans les blocs de construction dans f # (divisez les classes en structures de données et fonctions qui ont réagi). Mais pour la compréhension du sharepoint vue des entresockets, cela a fonctionné. J’appendais que le problème était orienté business / Web et je ne sais pas comment la technique pourrait fonctionner pour quelque chose d’un peu plus financier. Je pense que je capturerais probablement les fonctions comme des objects sans état et qu’elles devraient bien s’intégrer.

    Tout dépend du domaine dans lequel vous travaillez.

    Vous pouvez créer un modèle de réseau de processus de stream de données tel que décrit dans Traitement du signal en temps réel: stream de données, programmation visuelle et fonctionnelle par Hideki John Reekie

    Par exemple pour du code comme (Haskell):

     fact n | n == 0 = 1 | otherwise = n * fact (n - 1) 

    La représentation visuelle serait:

    entrer la description de l'image ici

    J’utilise USL – Universal Systems Language. J’apprends Erlang et je pense que c’est un ajustement parfait.

    Dommage que la documentation soit très limitée et que personne ne l’utilise. Plus d’informations ici .