Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
The community reviewed whether to reopen this question 2 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
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.
Functional programmers generally don't have a lot of use for diagrams. Many functional programmers (but not all) find that writing down types is a good way to encapsulate the design relationships that OO programmers put into UML diagrams.
Because mutable state is rare in functional programs, there are no mutable "objects", so it is not usually useful or necessary to diagram relationships among them. And while one function might call another, this property is usually not important to the overall design of a system but only to the implementation of the function doing the calling.
If I were feeling a strong need to diagram a functional program I might use a concept map in which types or functions play the role of concepts.
UML isn't only class diagrams.
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".
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).
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.
To model a functional program, using a diagram, and not textual representation, you can use notation like the one used to program in Viskell or Luna
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 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 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.
I guess you could create a class called noclass and put in functions as methods. Also, you might want to split noclass into multiple categories of functions.
I am very new to c++ and confused between what is the difference between modular programming and function oriented programming.I have never done modular programming so I just know modules by definition that it contains functions.So what is the difference between a sequential(function-oriented language)and modular programming?Thanks in advance.
EDIT:
I was reading about C++'s OOP.It started something like what is unstructured programming, than gave a basic idea about structured programming, than modular programming and finally,OOP.
Modular programming is mostly a strategy to reduce coupling in a computer program, mostly by means of encapsulation.
Before modular programming, local coherence of the code was ensured by structured programming, but global coherence was lacking: if you decided that your spell-checking dictionary would be implemented as a red-black tree, then this implementation would be exposed to everyone else in the program, so that the programmer working on, say, text rendering, would be able to access the red-black tree nodes to do meaningful things with them.
Of course, this became hell once you needed to change the implementation of your dictionary, because then you would have to fix the code of other programmers as well.
Even worse, if the implementation detail involved global variables, then you had to be exceedingly careful of who changed them and in what order, or strange bugs would crop up.
Modular programming applied encapsulation to all of this, by separating the implementation (private to the module) from the interface (what the rest of the program can use). So, a dictionary module could expose an abstract type that would only be accessible through module functions such as findWord(word,dictionary). Someone working on the dictionary module would never need to peek outside that module to check if someone might be using an implementation detail.
They are both ways of structuring your code. If your interested in function-oriented programming and want to understand it a bit better, I'd take a look at lisp. C++ isn't truly function oriented as every function should return a value yet C++ functions can return void (making it a procedure rather than a function), so it's not a true functional programming language in the sense.
"I have never done modular programming so I just know modules by definition that it contains functions".
Modules are a level higher than functions.
That's a good start. Think of a function as a unit of work that does something and when you have several functions that you can group in a certain way, you put them in a module. So, string.h has a bunch of functions for working with strings, but you simply include the header and you have access to all those functions directly. You can then reuse those modules in other projects as you'd already used the modules previously and they've been (I assume) debugged and tested and stop people from reinventing the wheel. The whole point is to benefit from the cumulative experience.
I'd suggest you think of a project you'd like and write some functions and think about how you'd like to organize the code for another developer to use.
Hope this is of some use to you.
I believe functional programming leads us to micro services paradigm as for now while modular programming tends to similar to OOP concept.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Software Engineering as it is taught today is entirely focused on object-oriented programming and the 'natural' object-oriented view of the world. There is a detailed methodology that describes how to transform a domain model into a class model with several steps and a lot of (UML) artifacts like use-case-diagrams or class-diagrams. Many programmers have internalized this approach and have a good idea about how to design an object-oriented application from scratch.
The new hype is functional programming, which is taught in many books and tutorials. But what about functional software engineering?
While reading about Lisp and Clojure, I came about two interesting statements:
Functional programs are often developed bottom up instead of top down ('On Lisp', Paul Graham)
Functional Programmers use Maps where OO-Programmers use objects/classes ('Clojure for Java Programmers', talk by Rich Hickley).
So what is the methodology for a systematic (model-based ?) design of a functional application, i.e. in Lisp or Clojure? What are the common steps, what artifacts do I use, how do I map them from the problem space to the solution space?
Thank God that the software-engineering people have not yet discovered functional programming. Here are some parallels:
Many OO "design patterns" are captured as higher-order functions. For example, the Visitor pattern is known in the functional world as a "fold" (or if you are a pointy-headed theorist, a "catamorphism"). In functional languages, data types are mostly trees or tuples, and every tree type has a natural catamorphism associated with it.
These higher-order functions often come with certain laws of programming, aka "free theorems".
Functional programmers use diagrams much less heavily than OO programmers. Much of what is expressed in OO diagrams is instead expressed in types, or in "signatures", which you should think of as "module types". Haskell also has "type classes", which is a bit like an interface type.
Those functional programmers who use types generally think that "once you get the types right; the code practically writes itself."
Not all functional languages use explicit types, but the How To Design Programs book, an excellent book for learning Scheme/Lisp/Clojure, relies heavily on "data descriptions", which are closely related to types.
So what is the methodology for a systematic (model-based ?) design of a functional application, i.e. in Lisp or Clojure?
Any design method based on data abstraction works well. I happen to think that this is easier when the language has explicit types, but it works even without. A good book about design methods for abstract data types, which is easily adapted to functional programming, is Abstraction and Specification in Program Development by Barbara Liskov and John Guttag, the first edition. Liskov won the Turing award in part for that work.
Another design methodology that is unique to Lisp is to decide what language extensions would be useful in the problem domain in which you are working, and then use hygienic macros to add these constructs to your language. A good place to read about this kind of design is Matthew Flatt's article Creating Languages in Racket. The article may be behind a paywall. You can also find more general material on this kind of design by searching for the term "domain-specific embedded language"; for particular advice and examples beyond what Matthew Flatt covers, I would probably start with Graham's On Lisp or perhaps ANSI Common Lisp.
What are the common steps, what artifacts do I use?
Common steps:
Identify the data in your program and the operations on it, and define an abstract data type representing this data.
Identify common actions or patterns of computation, and express them as higher-order functions or macros. Expect to take this step as part of refactoring.
If you're using a typed functional language, use the type checker early and often. If you're using Lisp or Clojure, the best practice is to write function contracts first including unit tests—it's test-driven development to the max. And you will want to use whatever version of QuickCheck has been ported to your platform, which in your case looks like it's called ClojureCheck. It's an extremely powerful library for constructing random tests of code that uses higher-order functions.
For Clojure, I recommend going back to good old relational modeling. Out of the Tarpit is an inspirational read.
Personally I find that all the usual good practices from OO development apply in functional programming as well - just with a few minor tweaks to take account of the functional worldview. From a methodology perspective, you don't really need to do anything fundamentally different.
My experience comes from having moved from Java to Clojure in recent years.
Some examples:
Understand your business domain / data model - equally important whether you are going to design an object model or create a functional data structure with nested maps. In some ways, FP can be easier because it encourages you to think about data model separately from functions / processes but you still have to do both.
Service orientation in design - actually works very well from a FP perspective, since a typical service is really just a function with some side effects. I think that the "bottom up" view of software development sometimes espoused in the Lisp world is actually just good service-oriented API design principles in another guise.
Test Driven Development - works well in FP languages, in fact sometimes even better because pure functions lend themselves extremely well to writing clear, repeatable tests without any need for setting up a stateful environment. You might also want to build separate tests to check data integrity (e.g. does this map have all the keys in it that I expect, to balance the fact that in an OO language the class definition would enforce this for you at compile time).
Prototying / iteration - works just as well with FP. You might even be able to prototype live with users if you get very extremely good at building tools / DSL and using them at the REPL.
OO programming tightly couples data with behavior. Functional programming separates the two. So you don't have class diagrams, but you do have data structures, and you particularly have algebraic data types. Those types can be written to very tightly match your domain, including eliminating impossible values by construction.
So there aren't books and books on it, but there is a well established approach to, as the saying goes, make impossible values unrepresentable.
In so doing, you can make a range of choices about representing certain types of data as functions instead, and conversely, representing certain functions as a union of data types instead so that you can get, e.g., serialization, tighter specification, optimization, etc.
Then, given that, you write functions over your adts such that you establish some sort of algebra -- i.e. there are fixed laws which hold for these functions. Some are maybe idempotent -- the same after multiple applications. Some are associative. Some are transitive, etc.
Now you have a domain over which you have functions which compose according to well behaved laws. A simple embedded DSL!
Oh, and given properties, you can of course write automated randomized tests of them (ala QuickCheck).. and that's just the beginning.
Object Oriented design isn't the same thing as software engineering. Software engineering has to do with the entire process of how we go from requirements to a working system, on time and with a low defect rate. Functional programming may be different from OO, but it does not do away with requirements, high level and detailed designs, verification and testing, software metrics, estimation, and all that other "software engineering stuff".
Furthermore, functional programs do exhibit modularity and other structure. Your detailed designs have to be expressed in terms of the concepts in that structure.
One approach is to create an internal DSL within the functional programming language of choice. The "model" then is a set of business rules expressed in the DSL.
See my answer to another post:
How does Clojure aproach Separation of Concerns?
I agree more needs to be written on the subject on how to structure large applications that use an FP approach (Plus more needs to be done to document FP-driven UIs)
While this might be considered naive and simplistic, I think "design recipes" (a systematic approach to problem solving applied to programming as advocated by Felleisen et al. in their book HtDP) would be close to what you seem to be looking for.
Here, a few links:
http://www.northeastern.edu/magazine/0301/programming.html
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371
I've recently found this book:
Functional and Reactive Domain Modeling
I think is perfectly in line with your question.
From the book description:
Functional and Reactive Domain Modeling teaches you how to think of the domain model in terms of pure functions and how to compose them to build larger abstractions. You will start with the basics of functional programming and gradually progress to the advanced concepts and patterns that you need to know to implement complex domain models. The book demonstrates how advanced FP patterns like algebraic data types, typeclass based design, and isolation of side-effects can make your model compose for readability and verifiability.
There is the "program calculation" / "design by calculation" style associated with Prof. Richard Bird and the Algebra of Programming group at Oxford University (UK), I don't think its too far-fetched to consider this a methodology.
Personally while I like the work produced by the AoP group, I don't have the discipline to practice design in this way myself. However that's my shortcoming, and not one of program calculation.
I've found Behavior Driven Development to be a natural fit for rapidly developing code in both Clojure and SBCL. The real upside of leveraging BDD with a functional language is that I tend to write much finer grain unit tests than I usually do when using procedural languages because I do a much better job of decomposing the problem into smaller chunks of functionality.
Honestly if you want design recipes for functional programs, take a look at the standard function libraries such as Haskell's Prelude. In FP, patterns are usually captured by higher order procedures (functions that operate on functions) themselves. So if a pattern is seen, often a higher order function is simply created to capture that pattern.
A good example is fmap. This function takes a function as an argument and applies it to all the "elements" of the second argument. Since it is part of the Functor type class, any instance of a Functor (such as a list, graph, etc...) may be passed as a second argument to this function. It captures the general behavior of applying a function to every element of its second argument.
Well,
Generally many Functional Programming Languages are used at universities for a long time for "small toy problems".
They are getting more popular now since OOP has difficulties with "paralel programming" because of "state".And sometime functional style is better for problem at hand like Google MapReduce.
I am sure that, when functioanl guys hit the wall [ try to implement systems bigger than 1.000.000 lines of code], some of them will come with new software-engineering methodologies with buzz words :-). They should answer the old question: How to divide system into pieces so that we can "bite" each pieces one at a time? [ work iterative, inceremental en evolutionary way] using Functional Style.
It is sure that Functional Style will effect our Object Oriented
Style.We "still" many concepts from Functional Systems and adapted to
our OOP languages.
But will functional programs will be used for such a big systems?Will they become main stream? That is the question.
And Nobody can come with realistic methodology without implementing such a big systems, making his-her hands dirty.
First you should make your hands dirty then suggest solution. Solutions-Suggestions without "real pains and dirt" will be "fantasy".
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
The community reviewed whether to reopen this question 2 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
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.
Functional programmers generally don't have a lot of use for diagrams. Many functional programmers (but not all) find that writing down types is a good way to encapsulate the design relationships that OO programmers put into UML diagrams.
Because mutable state is rare in functional programs, there are no mutable "objects", so it is not usually useful or necessary to diagram relationships among them. And while one function might call another, this property is usually not important to the overall design of a system but only to the implementation of the function doing the calling.
If I were feeling a strong need to diagram a functional program I might use a concept map in which types or functions play the role of concepts.
UML isn't only class diagrams.
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".
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).
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.
To model a functional program, using a diagram, and not textual representation, you can use notation like the one used to program in Viskell or Luna
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 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 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.
I guess you could create a class called noclass and put in functions as methods. Also, you might want to split noclass into multiple categories of functions.
I've found UML useful for documenting various aspects of OO systems, particularly class diagrams for overall architecture and sequence diagrams to illustrate particular routines. I'd like to do the same kind of thing for my clojure applications. I'm not currently interested in Model Driven Development, simply on communicating how applications work.
Is UML a common / reasonable approach to modelling functional programming? Is there a better alternative to UML for FP?
the "many functions on a single data structure" approach of idiomatic Clojure code waters down the typical "this uses that" UML diagram because many of the functions end up pointing at map/reduce/filter.
I get the impression that because Clojure is a somewhat more data centric language a way of visualizing the flow of data could help more than a way of visualizing control flow when you take lazy evaluation into account. It would be really useful to get a "pipe line" diagram of the functions that build sequences.
map and reduce etc would turn these into trees
Most functional programmers prefer types to diagrams. (I mean types very broadly speaking, to include such things as Caml "module types", SML "signatures", and PLT Scheme "units".) To communicate how a large application works, I suggest three things:
Give the type of each module. Since you are using Clojure you may want to check out the "Units" language invented by Matthew Flatt and Matthias Felleisen. The idea is to document the types and the operations that the module depends on and that the module provides.
Give the import dependencies of the interfaces. Here a diagram can be useful; in many cases you can create a diagram automatically using dot. This has the advantage that the diagram always accurately reflects the code.
For some systems you may want to talk about important dependencies of implementations. But usually not—the point of separating interfaces from implementations is that the implementations can be understood only in terms of the interfaces they depend on.
There was recently a related question on architectural thinking in functional languages.
It's an interesting question (I've upvoted it), I expect you'll get at least as many opinions as you do responses. Here's my contribution:
What do you want to represent on your diagrams? In OO one answer to that question might be, considering class diagrams, state (or attributes if you prefer) and methods. So, obviously I would suggest, class diagrams are not the right thing to start from since functions have no state and, generally, implement one function (aka method). Do any of the other UML diagrams provide a better starting point for your thinking? The answer is probably yes but you need to consider what you want to show and find that starting point yourself.
Once you've written a (sub-)system in a functional language, then you have a (UML) component to represent on the standard sorts of diagram, but perhaps that is too high-level, too abstract, for you.
When I write functional programs, which is not a lot I admit, I tend to document functions as I would document mathematical functions (I work in scientific computing, lots of maths knocking around so this is quite natural for me). For each function I write:
an ID;
sometimes, a description;
a specification of the domain;
a specification of the co-domain;
a statement of the rule, ie the operation that the function performs;
sometimes I write post-conditions too though these are usually adequately specified by the co-domain and rule.
I use LaTeX for this, it's good for mathematical notation, but any other reasonably flexible text or word processor would do. As for diagrams, no not so much. But that's probably a reflection of the primitive state of the design of the systems I program functionally. Most of my computing is done on arrays of floating-point numbers, so most of my functions are very easy to compose ad-hoc and the structuring of a system is very loose. I imagine a diagram which showed functions as nodes and inputs/outputs as edges between nodes -- in my case there would be edges between each pair of nodes in most cases. I'm not sure drawing such a diagram would help me at all.
I seem to be coming down on the side of telling you no, UML is not a reasonable way of modelling functional systems. Whether it's common SO will tell us.
This is something I've been trying to experiment with also, and after a few years of programming in Ruby I was used to class/object modeling. In the end I think the types of designs I create for Clojure libraries are actually pretty similar to what I would do for a large C program.
Start by doing an outline of the domain model. List the main pieces of data being moved around the primary functions being performed on this data. I write these in my notebook and a lot of the time it will be just a name with 3-5 bullet points underneath it. This outline will probably be a good approximation of your initial namespaces, and it should point out some of the key high level interfaces.
If it seems pretty straight forward then I'll create empty functions for the high level interface, and just start filling them in. Typically each high level function will require a couple support functions, and as you build up the whole interface you will find opportunities for sharing more code, so you refactor as you go.
If it seems like a more difficult problem then I'll start diagramming out the structure of the data and the flow of key functions. Often times the diagram and conceptual model that makes the most sense will depend on the type of abstractions you choose to use in a specific design. For example if you use a dataflow library for a Swing GUI then using a dependency graph would make sense, but if you are writing a server to processing relational database queries then you might want to diagram pools of agents and pipelines for processing tuples. I think these kinds of models and diagrams are also much more descriptive in terms of conveying to another developer how a program is architected. They show more of the functional connectivity between aspects of your system, rather than the pretty non-specific information conveyed by something like UML.