LabVIEW
auto creation of flow diagrams
@nistudent wrote:
code was designed before just noone wants to go through the hard work of doing to documentation properly on a flow program as takes so long. was just after a faster solution from NI that might show the flow in far more detail and auto generate it from the code you are using. dont see why it would be so difficult to an application that does it. will be waiting.
It would be difficult because a flowchart contains domain knowledge that is not apparent in the written code. It is there but not in a way that can easily be determinded. As tst alrady said you are trying to reverse the development model.
Proper software development means designing the software algorithme first through flowdiagram, SDL, NassySchneiderman or whatever means and AFTER that start implementing it, not the other side around. All an automated tool could do is create a 1:1 analogy between what the LabVIEW diagram is and that perverts the purpose of such documentation which should be to show a more concise way of what your program is supposed to do (contrary to what it is doing 😉
Rolf Kalbermatter
Message Edited by rolfk on 06-29-2007 02:41 PM
An equally significant problem is that it might not even be able to represent a LV program as a flow chart. The reason for this is that flowcharts were born in a world of linear code (think BASIC or C) execution where the program's structure was viewed in relation to the flow of time. Basically, program execution started at the top of the page and proceeded until it got to the bottom of the page, at which point the program stopped. Flowcharts are very good at this sort of structure.
However, as things progressed people began to realize in the early '70s that using flowcharts created problems. For instance they saw that starting a design project with a flowchart is almost always wrong. Moreover, as programs got more complex the essentially 1D representation of a program wasn't up to the task of describing the highly-parallel, hierarchical nature of large well-written programs.
...and this is the problem with flowchart in relation to LabVIEW. A well-designed LV program's structure consists of a set of manipulations that are performed on data. Some of these manipulations are dependent upon one another and so happen sequentially. Sometimes that are independent in which case they proceed in parallel. Likewise, any non-trivial LV application has a pronounced hierarchical structure. Therefore trying to do a flowchart of a non-trivial LV application is like trying to accurately describe a sphere in 2 dimensions. Distortions invariably arise - distortions which defeat the purpose of having the document in the first place.
WARNING Rant Alert!
That is a studied, logical, professional, academic discussion of the issue of flowcharts as they relate to LV applications. In terms of the broader issue of program documentation I tend to be less studied, logical, professional and academic. I prefer blunt. So to the people who want to write code, but not document it I would say: "Stop whining and get on with the rest of your job!" These people cry and lament for want of documentation when they're stuck working on code they didn't create, but they would rather eat meadow muffins than document the code they produce. I'm sorry but you can't have it both ways.
Nobody writes code that is so logical, intuitive and bug-free that it doesn't need to be documented. Which reminds me, in my experience there are few things I can do after-the-fact to improve the quality of the code I write more than document it. I can't tell you how many thousands of bugs I have caught through the process of documenting what I had done. If you write code but are the only one who knows how it works you haven't finished the job.
There... I feel much better...
Mike...
However, as things progressed people began to realize in the early '70s that using flowcharts created problems. For instance they saw that starting a design project with a flowchart is almost always wrong. Moreover, as programs got more complex the essentially 1D representation of a program wasn't up to the task of describing the highly-parallel, hierarchical nature of large well-written programs.
...and this is the problem with flowchart in relation to LabVIEW. A well-designed LV program's structure consists of a set of manipulations that are performed on data. Some of these manipulations are dependent upon one another and so happen sequentially. Sometimes that are independent in which case they proceed in parallel. Likewise, any non-trivial LV application has a pronounced hierarchical structure. Therefore trying to do a flowchart of a non-trivial LV application is like trying to accurately describe a sphere in 2 dimensions. Distortions invariably arise - distortions which defeat the purpose of having the document in the first place.
WARNING Rant Alert!
That is a studied, logical, professional, academic discussion of the issue of flowcharts as they relate to LV applications. In terms of the broader issue of program documentation I tend to be less studied, logical, professional and academic. I prefer blunt. So to the people who want to write code, but not document it I would say: "Stop whining and get on with the rest of your job!" These people cry and lament for want of documentation when they're stuck working on code they didn't create, but they would rather eat meadow muffins than document the code they produce. I'm sorry but you can't have it both ways.
Nobody writes code that is so logical, intuitive and bug-free that it doesn't need to be documented. Which reminds me, in my experience there are few things I can do after-the-fact to improve the quality of the code I write more than document it. I can't tell you how many thousands of bugs I have caught through the process of documenting what I had done. If you write code but are the only one who knows how it works you haven't finished the job.
There... I feel much better...
Mike...
