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 1 year ago.
Improve this question
Looking for best practices where graphs are used to describe relationships between Modelica models. For example, component hierarchy, inheritance, dependencies between packages, combinations of all the above, etc.
The real problem is to find a good compromise between information and diagram complexity, especially for industrial-scale models.
Any suggestions would be appreciated. It's perfectly fine if it is not Modelica, but related.
Note: This questions was flagged as "not meeting Stackoverflow guidelines" (?), hence I had to edit it. That means the earlier replies were to the original wording.
I don't really have any good examples, so I just share some opinions.
There should be two kinds of graphs.
My thought is there must be two kinds of graphs, one is simplified, which is about the equation structure, and the other one is detailed, which is about the inheritance and dependencies, combination, and all the other stuff.
Whatever simulation tool or language you use, in the end, simulation is about how to solve equations, especially nonlinear and complex equations. so if you could tell the users which equation belongs to which component or is generated by which connection, it would be really helpful. One of the issues I often struggle to solve is to find which equations cause nonlinearity and takes too much CPU time to do iterations. Right now, Dymola provides users options to see the final equation structures, but it doesn't show which equation belongs to which components, as far as I know, Wolfram System Modeler does.
As to the detailed information, I think sourcetrail is a good example, although it is designed for C++. Interactivity GUI is what attracts my eyes, especially for modelers, so imagine if you see a very detailed dependency diagram of different models, it is hard for anyone to get useful information, so it must be interactive like the sorcetrail does, so it could be readable for human.
My ideas about the detailed graph.
I think every piece of information is useful, just like Wikipedia, the key point is how to organize the information.
Firstly let's take Modelica.Electrical.Analog.Examples.HeatingMOSInverter as an example. In the following screenshot, we could apparently see there are different Loops related to 2 different domains, which are Electrical and Thermal. So the first rule we should establish is to divide a large model into subsystems based on different domains.
Secondly, let's take Modelica.Electrical.Analog.Examples.CauerLowPassAnalog as an example, which only includes electrical components from Modelica.Electrical. Although this model just includes electrical components, there are a few Loops in this model, so it would be definitely better to understand if we could split the model into smaller Loops when generating a class dependency diagram. In the end, there would be two kinds of 1-domain subsystems: Loop and Branch, which are connected by dummy connectors.
Thirdly, let's take the electrical part of Modelica.Electrical.Analog.Examples.HeatingResistor as the example, marked by the green square.
The class dependency diagram of this kind of 1-domain model would be like the following picture, although the following screenshot is about another example, it could explain that even for the 1-domain model, it is hard to link this class dependency diagram with your real models.
So we should keep the model's topology structure when generating a class dependency diagram. There are different layers in this diagram: Basis layer, Abstract components layer, Directly used components layer, Model layer. To make the diagram more clear, it could also be 3D. It should look like this:
I think it should be the library developer's duty to adopt good hierarchies to make this diagram look clear and clean. For example, all Abstract components should be partial model, so it could easy to recognize them. Or there could be an extra marker variable in each class to mark that the class belongs to which layer. For now, we could use all partial models as Abstract components, all non-partial models as Directly used components, which could make the diagram unclear， but it is better than nothing.
Note: there are two important relationships between different layers: Extends and Instantiates, it could be marked by different lines or colors.
When it comes to multi-domain modeling, there should be two separate class dependency diagrams that are connected through these multi-domain components.
To summarize, I think we should generate a class dependency diagram for a single Loop that only includes 1-domain components, and then combine all the diagrams for a single Loop, we will get the whole diagram of the whole model. So in some way, we could keep the original model's topology structure.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Could you recommend some good articles/notes/tutorials on finite element method (FEM)? I don't deal with advanced math every day, so a tutorial that introduces me to math needed to understand FEM will be great.
My goal is to write my own simulation of deformable bodies (+plasticity). I must use FEM, but it will be good if I will know BEM (Boundary element method) and FDM (Finite difference method) too.
Really understanding Finite Element Methods requires quite a bit of fairly advanced mathematics; unless you have a few years to devote to the cause, let's leave that aside for now.
That said, the basic ideas underlying FEM are fairly simple if you have some experience with ODE solvers. Can you tell us some more about your background and what you really want to learn so that we can suggest some appropriate resources? Do you want to learn the underlying mathematics, or do you just want to learn some cookbook recipes for applying FEM to a certain class of problem?
Your question is unclear. I don't know what you want to know, because it's impossible to tell what you're ignorant of here.
You don't deal with advanced math every day. What do you know about the finite element method? Here are topics you'll need to know:
Statics and dynamics; how to draw free body diagrams
Solid mechanics - strength of materials, elasticity,
Continuum mechanics for large strain models: Lagrangian and Eulerian formulations
Material models - elasticity and plasticity
Partial differential equations
Method of weighted residuals and integral equations
Linear algebra
Numerical methods
Geometric modeling - CAD for geometry and meshing for FEA models
Commercial or open source packages
You don't say whether you want to use a commercial package (ANSYS, NASTRAN, ABAQUS) or something that you'll write.
As far as references go, there are lots of books available now, but they aren't easy to read or absorb. I'd recommend T.J.R. Hughes' Dover book on the subject. It's cheap and good.
But it's not easy.
I just skimmed through the paper. It looks like a survey article, with nothing new to contribute to the state of the art. It covers a lot more than just small strain plasticity of metals. I see fabric models, large strain problems, etc.
It also mentions boundary element methods and finite difference methods. Do you want to know about those, too? Boundary element methods are completely different from finite elements. The former are based on Green's function formulations; the latter use method of weighted residuals.
The paper doesn't have a great deal of depth to it, but it's very broad. What do you want to know?
I don't think it's possible for someone with so little background to write their own. A better place to start would be FENICS.
I can recommend Introduction to Finite Element Methods by Carlos A. Felippa. It is relativly easy to read.
You can find it here, the Chapters are linked on the main page.
Only the direct stiffness method is covered, think of deformations of trusses without time considerations.
It follows a very nice 'hands-on' approach with examples in Mathematica which are well suited for developer folks.
A really good introduction to FEA for beginners is "Practical Stress Analysis with Finite Elements" by Bryan J Mac Donald. This concentrates on stress analysis but shows you how the method works from both a practical and a theoretical point of view. Unlike a lot of other books it is not specific to any particular software and it is written in plain, easy-to-understand language.
UPDATE: I had posted this on UI.stackexchange also for views on different kinds od visualisation. I am posting this here for finding out the programming techniques and tools required to do so.
Let us have the following three sets of information
Now I want to combine all of this data and show it all together. Telling it like a story. Giving inter-relations. Showing similarities in terms, concepts etc. to get the following (Note that in the diagram below, the colored relations may not be exact, they are merely indicative of a node of information)
Situation: I need to tell somebody the relation between two or more important things through the commonness of concepts, keywords, behaviours in those things.
One way that I figured out would be to use circles for concepts.
So that all concepts connected to thing A would be connected to it and all concept related to B would be connected to it. And the common concepts would be connected to both. That way 2 things can be easily compared.
Problem: To build such a graph/visualisation manually would be cumbersome. Especially to add, arrange, update and manipulate.
Question: Is there a good way to do it. Also, Is there a tool available for doing this?
I hope this make the question much more clear. :)
Where does this data (the concepts, keywords, and relations between them etc...) come from? If it's in a database somewhere you could write soem code to generate a graphiz file then open it in a graphiz visualizer. There might be some tools out there that allow interactive editing of a graphiz graph, it looks like WebDot may and there are probably others.
How to display the hierarchical data on User Interface
You're talking about Venn diagrams. I think there should be plenty of online and offline tools that can help making these.
graphiz has been mentioned already, although that would be used more to show a flow of a system, or a treeview.
When you're talking about software development and want to display a design through diagrams, a complete diagram solution already exist as UML. And there are plenty of UMT tools that can help here. A commercial version is Altova UModel, which has some very nice features. You could probably use Use Cases as the most logical diagram type.
Also see Wikipedia for more info about use case diagrams. Reconsidering the image you've added, I do tend to consider it to be a usecase. Since UML is based on XML, it should be possible to transform your data through a stylesheet to UML, then use a random UML tool to display the diagrams.To convert your data to XML, well... If it's in Excel then exporting it to XML should not be too difficult.
Why is your sample image an Use Case? Well, you have actors (Pinguin, Koala, Tulips) and you have actions. (well, kind of actions: Cause for concern, some kind of animal, linked to movie, bites your nose off...) And finally, there are associations between the actors and the actions connecting them all in some way. Thus Data--(export)->XML--(Styleheet)->UML--(UML tool)->Diagram.
D3: Data-Driven Documents JS library
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.