17

Absolutely. Whenever I'm implementing something that I haven't done before (and the algorithm takes more than a few steps), I'll chart it out. I find that it really forces me to analyze the entire solution at a more atomic level and more thoroughly than if it wasn't charted out. I find that there are three major benefits to this practice: Fewer "oh craps" ...


12

I feel Message Sequence Chart/Sequence diagram is better suited for documenting RESTful API interaction. What you have is a state diagram, while RESTful API by definition is stateless.


12

Never Flowcharts - especially as practiced 25+ years ago - have been superseded by far more expressive diagramming techniques (c.f. Action Diagrams, Sequence Charts, State Charts, et al). IBM's own studies showed that the use of flowcharts had no effect on the quality of a system's design or implementation (though they were marginally useful for ...


9

I think what you're looking for here is a Sequence Diagram. These allow you to visualize the order in which various modules call eachother via the use of arrows. Constructing one is simple: Draw your starting class with a dotted line below it. Draw the next class/method in the call trace with a dotted line below that Connect the lines with an arrow, ...


7

Effectively, a flow chart is just a fancy graph. So, you will have nodes and edges. Nodes will have text, (optionally) position/size, and unique ids. Edges will have a pair of nodes and a name. So, suppose we have, "Ask user their name. If their name is Bob, compliment them. Otherwise, hang up on them." Something like this: var JsonGraph = { Root:...


7

I haven't drawn a classical flow chart since my first programming class in 1976, and haven't seen anyone else create one since the early 80's. Flow charts were useful to communicate program logic when the code was in assembly language. By the late 1960's, assembly language programmers were using pseudo-code. When programming in modern OO languages, ...


7

In short, a flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. You may also think of a flow chart as a process flow of application logic while connecting components in some type of flow of events. What about the constructors of classes, ...


6

Flowcharts and pseudocode often have the same level of expressiveness, but differ in linearization. Pseudocode is linear (i.e. a sequence of lines with instructions), a flowchart is not. Therefore, flowcharts are a higher abstraction level, used before writing pseudocode or for documentation. Flowcharts have, in my opinion, two strong advantages over ...


5

I use flowcharts all the time for a number of reasons: They are better than UML use case diagrams in my opinion. They can reflect a number of different use cases and how they interact, and they do a better job overall bringing the user experience and decisions together. They are easier to understand and more intuitive. Your mind naturally follows the ...


5

I think a call graph would be the most appropriate visualization. If you decide not to do it by hand, there's a nice little tool called pyan that does static analysis on a python file and can generate a visualized call graph by way of a graphviz dot file (which can be rendered to an image). There have been a couple of forks, but the most fully-featured one ...


4

I've not drawn a flowchart in over 20 years. Thank goodness. By the time the chart is done the code could have been written, debugged, and deployed. Flowcharts were OK at a time when everything was card-punched and batch processed on mainframe computers that were doing priority production runs w/ your development work squeezed in between; computer time was ...


4

The Wikipedia article covers this pretty well. Look under building blocks; if it's not there, a flowchart doesn't cover it. Flowcharts are mostly meant to illustrate a process that embodies an algorithm (a recipe for solving a problem). The flowchart illustrates the procedural steps that the computer would take to solve the problem.


3

I'd use a graph data structure. They are often implemented using adjacency matrices or adjacency lists. The MSDN has a pretty solid tutorial. The article covers both of the aforementioned structures.


3

This question is very broad, so just some general advice. Is there a nice way tot do this without taking too much time and confusion ? I know only one: ask the authors of the system if they can give you some explanation. If you cannot grasp any of the authors, you will have to start reengineering - no shortcut. Are there any softwares or debugging ...


3

Flowcharts are useful when things need to be done in a specific order. Where they really shine in my mind is showing where decisions are made and making sure that each possible decision has a path. This prevent creating programs where a mamager approval is required but have no way to deal with it if the manager (who approves 98% of the time) says no. They ...


3

This can work and this could be a terrible idea and it really depends on what you're trying to achieve. Positive example: Arena is a simulation software that uses predefined blocks to create new simulations. This works great since the constructs are similar between any two simulations and working with a graphical tool is beneficial for that kind of work. ...


3

This isn't really a "should" question. Does it work for you? Ok then do it. Scripts often have minimal debugging facilities so the old "printf" is jolly useful. Consider having a "verbose" mode and a "quiet" mode. If your programs get really complicated you're probably better off with a debugger (or perhaps just fix your unit tests...)


3

Yes, there is such a convention, but it is not based on true or false. The "happy flow" will always be pointing down and any exceptional or side-tracked flow will be pointing left/right. E.g. if you have a decision based on whether you are having to set up a new client or use an existing client, the existing client is the nice direction ==> go down.


2

I've recently done some flow-charting and struggled with the same issue, how to present subroutine calls, or perhaps method- and function -calls as you might call them these days. I settled on a convention that I separate subroutine CALLS from subroutine REFERENCES. For the former I use an ordinary rectangle showing the call with arguments being made, using ...


2

On Pseudo Code To be honest, I don't use pseudocode much. Typically it's faster to just write the code, so that when I'm done with my code, it's actual code. There are some cases when pseudo code may be helpful, but you're generally working on something very complex and just trying to break down the structure of a method or something. In those cases, I ...


2

You probably will want either a full traditional state diagram or a summary pseudo-state diagram. The full diagram would have a state circle for each of the (in your example) 72 states, and each of the transitions (including self loops). Such a diagram is good for documentation and study for modifications. It is easier to deal with than the C code as it ...


2

Flowcharts are to capture solution logic in a stable/readable form. If this is sufficient for your audience, that is all that matters. Is this for yourself or a different audience? What are the audiences expectations? Is there an established standard that they are expecting? If it is important to your logic that the variables be initialized, then add a ...


2

Is the algorithm done once you remove one block that does not meet the threshold? If not, you need a loop that iterates over each block. You also need an exit condition if you have no blocks that fail to meet the threshold. Maybe something like this? Start | V Split signal | V /------ More blocks? &...


2

If you are using flowcharts, then you can have 3 separate flowcharts. 1 to represent the overall view showing the decision that leads to initiating the service in the 2 different ways you say you have in your case. The other two diagrams will detail the process in each scenario. Flow charting is a loose technique with hardly any rules beyond what the shapes ...


2

In an ordinary flowchart (not a UML diagram), any box that represents some other process, subroutine or method (returning back to the caller) would be represented by a box having double-vertical lines instead of single, the Predefined Process Symbol. Return to the calling entity is indicated by flow control passing through the box, and out the other side, ...


2

Not to intentionally be a contrary, but in answer to the question: "What types of processes have to be reflected in flowchart?" I think the answer is none of them. Flow charts have been around a long time. For developers, they are time consuming to produce, particularly in the quantity that would be needed for a commercial scope project. They also ...


2

Generally speaking, all Inputs (via I/O box), Outputs (via I/O box), Processings(via Proceesing box) and Decisions (via Diamond box) should be reflected in your flowchart. Talking about events, they can be depcited somewhat via the diamond box if you like. For example: if (user/system does that) then do this else do this For constructors, you ...


2

When writing GoJS we solved this by having the following rules for data: Every node has a key, which must be unique Links can be represented one of two ways: In a Tree-like fashion (TreeModel), or as separate JSON object entities (GraphLinksModel) If the flowchart or diagram is created in a Tree-like fashion, with only one parent per Node, then you don't ...


2

Flowcharts represent flow of control, not flow of information. Flowcharting formally captures steps and the linkages between them that describe the transfer of the flow of control that are often based on decisions: in particular, conditional branches and loops. Flow of control is about what is done or happens next, and (sadly) not about the required data ...


Only top voted, non community-wiki answers of a minimum length are eligible