Reverse engineering - flowchart ?
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
I use EnterpriseArchitect[^] (best / easiest (and cheapest) modeling software, but still has a learning curve) for all my UML diagram creation. ** You can point the tool at your DB Schema and it will create the database diagram. Very nice. ** You can point the tool at your C#, Java (many languages included) code and it will create Class diagrams. It includes Activity diagrams (think flow diagrams) but there is no way to reverse engineer your code into an Activity diagram. I'm not sure if there is a software that does that type of thing. Maybe when ChatGPT grows up? :rolleyes: But there may be a tool out there I don't know.
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
Member 14968771 wrote:
"free" application which analyzes the app and produces nice flowchart ?
For reverse engineering linked binaries and generating a flow graph: [IDA Pro does graphing](https://www.google.co.uk/search?q=IDA+pro+graphing&source=lnms&tbm=isch) [Ghidra does graphing](https://www.google.co.uk/search?q=ghidra+graphing&source=lnms&tbm=isch) [Radare2 does graphing](https://www.google.co.uk/search?q=radare2+graphing&source=lnms&tbm=isch) I'm not actually sure if [IDA Free](https://hex-rays.com/ida-free/) generates graphs, I've never used the 'Free' version. But Ghidra and Radare2 both have what you are looking for.
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
You sound as if you hope to avoid having anything all all to do with flowcharts - just leave the problem to the machine so you can forget it. I think you will fail. First: If the job asks you to make a flowchart, it expects you to know how to do it - that is why they ask! If you can't do it yourself, all you can do is to ask a machine to do the job, then you are lacking the qualifications they are asking for. Second: A flowchart is like pseudocode. It shows what you intend to program, the overall logic flow. It should not reflect all those tiny little jumps and turns you do in the coding, but reflect the 'main ideas' and structure. Maybe these automatic analyzers can e.g. do flow analysis as a technique to suggest 'essential' code structures, but I guess you must spend quite some time to learn and control its logic. Maybe you will have to provide hints and corrections to make it produce decent flowcharts at the appropriate level. My guess is that if you spend a similar effort on creating the flowcharts 'by hand', you will end up with a much more satisfying result. Having a program to create flowcharts is like having a program to create pseudocode from your C/C++ source. All it can do is remove some details from the code; it cannot identify the intention of your constructs. Pseudocode and flowcharts are similar: They are meant to present the intention, what you attempt to build. They belong in the overall design/architecture phase of your project, not in the post-coding phase. Now, I am surprised that anyone is asked to flowchart their code in year 2023. I haven't seen a single coding flowchart since (long) before the turn of the millennium. Actually, I have never since I completed my studies in 1983 been asked by any employer do draw a code flowchart. Pseudocode, at a high, 'overview' level, is a different thing. Much more maintainable, more informative. And data flow between modules and subsystems requires documentation. Modern software is so complex that flowcharting it all at code level will fill multiple volumes, even for moderate size systems. 'Flow charts' at subsystem and module levels, along with data flow descriptions, is really a different animal from drawing a simple code loop as a diamond box with an arrow from one of the corners to the top of a rectangular box, the 'loop body', and an arrow from its bottom to the top of the diamond. (Is that the IBM style? I guess that it is something like that.) There is no benefit from expressing maybe five lines of plain co
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
-
You sound as if you hope to avoid having anything all all to do with flowcharts - just leave the problem to the machine so you can forget it. I think you will fail. First: If the job asks you to make a flowchart, it expects you to know how to do it - that is why they ask! If you can't do it yourself, all you can do is to ask a machine to do the job, then you are lacking the qualifications they are asking for. Second: A flowchart is like pseudocode. It shows what you intend to program, the overall logic flow. It should not reflect all those tiny little jumps and turns you do in the coding, but reflect the 'main ideas' and structure. Maybe these automatic analyzers can e.g. do flow analysis as a technique to suggest 'essential' code structures, but I guess you must spend quite some time to learn and control its logic. Maybe you will have to provide hints and corrections to make it produce decent flowcharts at the appropriate level. My guess is that if you spend a similar effort on creating the flowcharts 'by hand', you will end up with a much more satisfying result. Having a program to create flowcharts is like having a program to create pseudocode from your C/C++ source. All it can do is remove some details from the code; it cannot identify the intention of your constructs. Pseudocode and flowcharts are similar: They are meant to present the intention, what you attempt to build. They belong in the overall design/architecture phase of your project, not in the post-coding phase. Now, I am surprised that anyone is asked to flowchart their code in year 2023. I haven't seen a single coding flowchart since (long) before the turn of the millennium. Actually, I have never since I completed my studies in 1983 been asked by any employer do draw a code flowchart. Pseudocode, at a high, 'overview' level, is a different thing. Much more maintainable, more informative. And data flow between modules and subsystems requires documentation. Modern software is so complex that flowcharting it all at code level will fill multiple volumes, even for moderate size systems. 'Flow charts' at subsystem and module levels, along with data flow descriptions, is really a different animal from drawing a simple code loop as a diamond box with an arrow from one of the corners to the top of a rectangular box, the 'loop body', and an arrow from its bottom to the top of the diamond. (Is that the IBM style? I guess that it is something like that.) There is no benefit from expressing maybe five lines of plain co
I did not expect such in -depth analysis. and have to admit I did not analyze it much. But since you eluded to many drawback of letting the machine do the dirty work - my "example" is typical spaghetti code of 6 classes / objects inter-weaved with "events " processing. The various time consuming events are what driving me insane.... Generally a flowchart of the objects dependencies would be nice , that is all I am asking. Than I can handle the "events"....
-
You sound as if you hope to avoid having anything all all to do with flowcharts - just leave the problem to the machine so you can forget it. I think you will fail. First: If the job asks you to make a flowchart, it expects you to know how to do it - that is why they ask! If you can't do it yourself, all you can do is to ask a machine to do the job, then you are lacking the qualifications they are asking for. Second: A flowchart is like pseudocode. It shows what you intend to program, the overall logic flow. It should not reflect all those tiny little jumps and turns you do in the coding, but reflect the 'main ideas' and structure. Maybe these automatic analyzers can e.g. do flow analysis as a technique to suggest 'essential' code structures, but I guess you must spend quite some time to learn and control its logic. Maybe you will have to provide hints and corrections to make it produce decent flowcharts at the appropriate level. My guess is that if you spend a similar effort on creating the flowcharts 'by hand', you will end up with a much more satisfying result. Having a program to create flowcharts is like having a program to create pseudocode from your C/C++ source. All it can do is remove some details from the code; it cannot identify the intention of your constructs. Pseudocode and flowcharts are similar: They are meant to present the intention, what you attempt to build. They belong in the overall design/architecture phase of your project, not in the post-coding phase. Now, I am surprised that anyone is asked to flowchart their code in year 2023. I haven't seen a single coding flowchart since (long) before the turn of the millennium. Actually, I have never since I completed my studies in 1983 been asked by any employer do draw a code flowchart. Pseudocode, at a high, 'overview' level, is a different thing. Much more maintainable, more informative. And data flow between modules and subsystems requires documentation. Modern software is so complex that flowcharting it all at code level will fill multiple volumes, even for moderate size systems. 'Flow charts' at subsystem and module levels, along with data flow descriptions, is really a different animal from drawing a simple code loop as a diamond box with an arrow from one of the corners to the top of a rectangular box, the 'loop body', and an arrow from its bottom to the top of the diamond. (Is that the IBM style? I guess that it is something like that.) There is no benefit from expressing maybe five lines of plain co
trønderen wrote:
There is no benefit from expressing maybe five lines of plain code with boxes and arrows and labels and whathaveyou.
Yes, I'm going to argue with you. But it isn't an argument with you, it is an argument with this terrible uncommunicative industry we work in. If people actually learned how to communicate with the proper diagram then it would be useful. I will now prove my point with a diagram (image snapshot)[^]. Before Looking At the Diagram Here's the deal. As a Software Developer of the Inbound Fax Service, I was being complained at because other parts of the system were not doing their part. I took it upon myself and drew this Activity (high level flow) diagram which includes Swim Lanes. Do you understand how great Swim Lanes are? They indicate where the functionality of systems begins and ends. Take a look at the diagram and notice the swim lanes (marked with labels at the top). My system is the one I marked with This One in red. Quickly Digest Huge Amount of Info This diagram explains 6 systems and can be digested in 5-10 minutes. The Result This allowed me to tell people where the system was failing and why I was not able to fix those other problems (they are in another person's system) very quickly. I would receive calls about why the faxes were not being imported (ReadSoft lane), why the HDT was not converting the fax data properly (HDT), when would Ralcorp (receive fax data)? I could easily send the asker this diagram and explain the part that my system does. Now, would you rather have a code review (pick through code) to discover how these things work, or just read this very quick diagram. This Is What Is Wrong With The Industry Because people have not created good diagrams, everyone thinks all diagrams are rubbish. It is not true. The people creating the diagrams are rubbish. :rolleyes: Feedback? I am open to your feedback.
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
I don't know what a "fore hire" program - is that a test? Flowcharts are some times useful, but they go back to the days of well, ancient days. If a place is asking you for a flow chart... run
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
TL;DR Although what I am going to write is not strictly related to the question (I also do not know the software mentioned by the author of the post), I have read some answers that mention only flowcharts as the main way to document parts of software (the algorithmic ones). I would humbly like to bring my experience in terms of algorithm design. Over the years, I have often found myself having to solve intricate problems, often automation problems, but also having to concisely describe relatively complex algorithms that then have to be translated into actual code. In short, this is the algorithm design phase. In my experience, in some cases, flowcharts are too large to be read easily. It is also difficult to write them down, especially without the help of a drawing program. Leaving aside algorithms involving recursion, everything else falls into the third level of Noam Chomsky's hierarchy of grammars: regular ones. Since regular grammars are assimilated to finite-state automata, even a flowchart that contains no recursion can be traced back to a state machine. In fact, let us think of the various internal "loops" that constitute some parts of an algorithm described with a flowchart: we can think of them as internal states of an FSM and the transition from one "zone" (i.e., an internal loop) to another as the transition between two states with actions (calculations or side effects) related to the latter. This is as true for algorithms that never end (automation, IoT, etc.) as it is for computational or parsing algorithms. Describing rather complex algorithms with FSM instead of flowcharts allows much more compact representations. It is much easier to understand their operation. First, I want to say that the transformation of an FSM graph into a flowchart and then into code does not necessarily involve the use of state variables. In fact, in most cases they are not used at all: the mapping between the FSM and the flowchart is straightforward. One can also see a natural decomposition into functions (related to actions associated with transitions from one state to another), or to simplify the transition between states. But the translation directly from FSM to code is even more straightforward: one can translate the FSM into a flowchart only if required by the documentation protocol. But the greatest advantage of this approach is the verification of the complete consideration of all input states governing the evolution of the FSM and thus of the algorithm it describes. That is, it is possible to verif
-
When I wrote my first "for hire" program - in an assembly and no PC - part of the "for hire deal" was for the program to actually perform the requested task and BE DOCUMENTED. Required documentation included (IBM) flowchart... After much frustration muddling thru undocumented "free" C++ code example I am wondering if there is an "free" application which analyzes the app and produces nice flowchart ? Yes, I did ask Mrs Google... and got "Rhapsody" IBM Documentation[^] Any comments on "Rhapsody " would be appreciated. Any other options ? Cheers
-
I did not expect such in -depth analysis. and have to admit I did not analyze it much. But since you eluded to many drawback of letting the machine do the dirty work - my "example" is typical spaghetti code of 6 classes / objects inter-weaved with "events " processing. The various time consuming events are what driving me insane.... Generally a flowchart of the objects dependencies would be nice , that is all I am asking. Than I can handle the "events"....
You should read
trønderen's response again: Among other things:trønderen wrote:
"It shows what you intend to program, the overall logic flow. It should not reflect all those tiny little jumps"
A mechanical tool will never summarize your intention, or the essence, of your algorithm. You must find it within your own capabilities to concisely illustrate your algorithm. What you should be looking for is a manual flow-chart tool that is practical to use. IMO.
"If we don't change direction, we'll end up where we're going"
-
You sound as if you hope to avoid having anything all all to do with flowcharts - just leave the problem to the machine so you can forget it. I think you will fail. First: If the job asks you to make a flowchart, it expects you to know how to do it - that is why they ask! If you can't do it yourself, all you can do is to ask a machine to do the job, then you are lacking the qualifications they are asking for. Second: A flowchart is like pseudocode. It shows what you intend to program, the overall logic flow. It should not reflect all those tiny little jumps and turns you do in the coding, but reflect the 'main ideas' and structure. Maybe these automatic analyzers can e.g. do flow analysis as a technique to suggest 'essential' code structures, but I guess you must spend quite some time to learn and control its logic. Maybe you will have to provide hints and corrections to make it produce decent flowcharts at the appropriate level. My guess is that if you spend a similar effort on creating the flowcharts 'by hand', you will end up with a much more satisfying result. Having a program to create flowcharts is like having a program to create pseudocode from your C/C++ source. All it can do is remove some details from the code; it cannot identify the intention of your constructs. Pseudocode and flowcharts are similar: They are meant to present the intention, what you attempt to build. They belong in the overall design/architecture phase of your project, not in the post-coding phase. Now, I am surprised that anyone is asked to flowchart their code in year 2023. I haven't seen a single coding flowchart since (long) before the turn of the millennium. Actually, I have never since I completed my studies in 1983 been asked by any employer do draw a code flowchart. Pseudocode, at a high, 'overview' level, is a different thing. Much more maintainable, more informative. And data flow between modules and subsystems requires documentation. Modern software is so complex that flowcharting it all at code level will fill multiple volumes, even for moderate size systems. 'Flow charts' at subsystem and module levels, along with data flow descriptions, is really a different animal from drawing a simple code loop as a diamond box with an arrow from one of the corners to the top of a rectangular box, the 'loop body', and an arrow from its bottom to the top of the diamond. (Is that the IBM style? I guess that it is something like that.) There is no benefit from expressing maybe five lines of plain co
trønderen wrote:
I suspect that this employer really do not want you to flowchart the code lines, but will look at your flowcharts how good you are at extracting the essentials
I agree, but there is the chance that this is the kind of employer that no sane engineer wants to work for.
"If we don't change direction, we'll end up where we're going"
-
If you're old enough to do flowcharting, then you probably remember IBM's top down programming methodology: HIPO--Hierarchy plus Input-Process-Output. Still use it, still like it.
Yes, I am old enough... What I am getting from this "...beer talk, let's solve all world's problems..." is that some folks do not take a broader look at the subject. ( But that is OK ) I am not saying to use flowchart as THE ONLY MEANS to accomplish the task. I am looking at a tool to HELP analyze "event driven" spaghetti code. NOT to resolve the problems. I am no looking for flowchart to analyze this "comment" if( A+B) // if A plus B
-
You should read
trønderen's response again: Among other things:trønderen wrote:
"It shows what you intend to program, the overall logic flow. It should not reflect all those tiny little jumps"
A mechanical tool will never summarize your intention, or the essence, of your algorithm. You must find it within your own capabilities to concisely illustrate your algorithm. What you should be looking for is a manual flow-chart tool that is practical to use. IMO.
"If we don't change direction, we'll end up where we're going"
Isn't the problem that he did not write the code? I understood that he is trying to understand the connections inside existing code. He is seeking help to understand the general intention of a previous programmer.
