More specifically, how do you model a functional program, or one developed using the Functional Style (without classes) using a diagram, and not textual representation, is it at all possible and could someone please direct me towards the nearest application that would do this (open source, of free as in beer, if you please)
相关问题
- System sequence diagram - Can system request input
- Does Visual Studio 2010 Professional support UML m
- Relation between Function1 and Reader Monad
- Can a [GoF]-ConcreteSubject override the notify me
- scala passing function with underscore produces a
相关文章
- Is there something like the threading macro from C
- Learning F#: What books using other programming la
- Creating a list of functions using a loop in R
- Code Iris plugin on Android Studio
- When to use interfaces, and when to use higher ord
- Functors in Ocaml
- Java Lambda Referencing Enclosing Object: Replace
- Are 'currying' and 'composition' t
UML is an object approach because at graphical level you can not define functional modeling. A trick is to directly add constraints and notes at model and not in the diagram levels. I mean that you can write a full functional documentation on each model element directly in the metamodel and only display an object view using the UML editor. This is maybe stupid but I found this demo in French language exactly on the same subject and using EclipseUML Omondo : OCL and UML 2.2 (demo in French language 3mn): http://www.download-omondo.com/regle_ocl.swf
This demo explains how to add constraints directly on methods at metamodel level. The interesting point of this demo is that using a single model for the entire project allows to be flexible enough to extend traditional UML and avoid SysML, BPMN, DSL additionals models because all information is built on the top of the UML 2.2 metamodel. I don't know if it will be a success but this initiative is very interesting because reduce modeling complexity and open new frontiers !!
I realize this is an old thread but I'm not understanding the issue here.
A class is merely an abstraction of a concept that ties the functionality of it's methods together in a more human friendly way. For instance, the class WaveGenerator might include the methods Sine, Sawtooth and SquareWave. All three methods are clearly related to the class Generator. However, all three are also stateless. If designed correctly, they don't need to store state information outside of the method. This makes them stateless objects which - if I understand correctly - makes them immutable functions which are a core concept in the functional paradigm.
From a conceptual perspective I don't see any difference between
let Envelope Sine = ...
and
let Envelope Generator.Sine = ...
other than the fact that the latter might provide greater insight into the purpose of the function.
UML isn't only class diagrams, you know?
Most of the other diagram types (Use case diagrams, activity diagrams, sequence diagrams...) are perfectly applicable for a purely functional programming style. Even class diagrams could still be useful, if you simply don't use attributes and associations and interpret "class" as "collection of related functions".
UML is a compendium of different types of modeling. If you are talking about the Object Diagram (Class Diagram), well you are not going to find anything that fits your desired use. But if you are talking about an Interaction Diagram (Activity Diagram) or Requirements Diagram (Use Case Diagram), of course they will help you and are part of the UML base.
Functional programmers have their own version of UML, it is called Category Theory.
(There is a certain truth to this, but it is meant to be read with a touch of humour).
I haven't actually tried modelling a large system in UML and then going for a functional implementation, but I don't see why it shouldn't work.
Assuming the implementation was going to be Haskell, I would start by defining the types and their relationships using a class diagram. Allocate functions to classes by their main argument, but bear in mind that this is just an artefact of UML. If it was easier to create a fictional singleton object just to hold all the functions, that would be fine too. If the application needs state then I would have no problem with modelling that in a state chart or sequence diagram. If I needed a custom monad for application-specific sequencing semantics then that might become a stereotype; the goal would be to describe what the application does in domain terms.
The main point is that UML could be used to model a program for functional implementation. You have to keep in mind a mapping to the implementation (and it wouldn't hurt to document it), and the fit is far from exact. But it could be done, and it might even add value.