|
raddevus wrote: Rocket Science & Brain Surgery are easy. Licensing, on the other hand...
The first are scientific fields, the later was made because of lawyers...  
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: The first are scientific fields, the later was made because of lawyers...
Oh my gosh! That explains it exactly!! So funny (and true and scary)
|
|
|
|
|
#6 is the sys admin.
They don't need to use it
but only make sure the 5 that can do.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I suppose you wanted to answer raddevous instead of answering me.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I wasn't responding to anyone particular. Just to the idea that license for 6 only allows 5 at once or something like that, In these chains of responses, I never am quite sure how the response order will go or who is responding to whom. I usually name them if that is my response is a particular person.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: I never am quite sure how the response order will go or who is responding to whom.
The response will hang to the message where you click "Reply" and the answer to a message is indented one position deeper. Same indentation, same message as parent. It is as you were nesting "If" and "Else ifs"
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Understood. Makes sense. I just lose track of who I am answering and what level they are.
Getting old eyes, I guess.
I'll be 76 this year.
Thanx for your response.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
That's common with espensive software. The company has X licenses that can be used concurrently by all the authorized employees.
I had some nice quality time when the entire customer company was developing an ECU and we couldn't compile because all available GreenHills' licenses were used - even better when the IDE was open but the devs were doing entirely different things, or the devs in otehr timezones set the workstation in sleep (it didn't release the licenses) and went out for their night.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Cannot comment on such a software, since I never used it.
However, I strongly doubt you can obtain nice flow-charts from wild C++ code samples.
My two cents.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
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? 
But there may be a tool out there I don't know.
|
|
|
|
|
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
Ghidra does graphing
Radare2 does graphing
I'm not actually sure if IDA Free generates graphs, I've never used the 'Free' version. But Ghidra and Radare2 both have what you are looking for.
|
|
|
|
|
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 code with boxes and arrows and labels and whathaveyou.
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, leaving details out but focusing on the overview that you might use for a first-time introduction to your program, e.g. for some other guy who will take over the code maintenance. The charts will reveal how well you understand the task, and how you understand it. A machine analyzer can't know that.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
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.
|
|
|
|
|
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"
|
|
|
|
|
|
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.
|
|
|
|
|
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 verify that, state by state, we have not "forgotten" certain input configurations, that is, we have not forgotten to evaluate certain conditions.
Each input state is formed by the configuration of its constituent predicates. For us "engineers" a predicate is a pure function that return true or false.
The transition from one state to another (or staying in the same state), depend on repeated evaluations of predicates. If a predicate is true, there is the state transition with associated semantic action to be performed. A state can be associated with multiple predicates to be evaluated. The predicates associated with a state, all together, form a set of possibilities with cardinality 2^N, where N is the number of predicates. Now, it is simple to check whether each combination of the values computed from the predicates (input state) has been taken into account for each state. When I say "taken into account," I also mean when some of these predicates have no effect on that processing step (they are considered as "don't care"). If there are any combinations of inputs (states) that have not been considered it is immediately seen. So it is very easy to reduce bugs caused by distractions in the design (rare but possible cases of input conditions).
That said, I have been using this technique for 30 years when some algorithmic parts are a little more complicated than normal. It is definitely a powerful system for handling automation problems, but not only that.
In addition, if you can describe an algorithm as a "state machine," you can describe it with bubble diagrams using a textual representation as a comment in the code (perhaps using the "dot" language with "graphviz") to be transformed into a drawing by pasting the text on an online viewer.
Needless to say, the process was "borrowed" from the hardware design of logic circuits.
Because I'm lazy, even mentally, and I don't like complexity in things at all, I developed a personal notation related to the labels of the arcs of the transitions of the bubble diagrams. I think it's been 30 years since I've drawn a flowchart. In fact, the biggest problem concerns the bloating of input state descriptions (listing all predicates, perhaps explicitly, leads to very long texts).
They consist of three parts, which I enclose in three distinct geometric figures, all written on the same line.
The first part is the "priority." That is, which predicate(s) are valued first over others. Evaluating one predicate alone first excludes it from transcription into the remaining ones. In this case I enclose a priority number from 1 to N in a triangle.
The second part, usually put in a rectangle (optional) is the actual "predicate".
The third part, enclosed in a circle, is the "semantic action" associated with the transition.
Each arc can include multiple transitions each with its own reference line.
When an algorithm has been developed with this notation, it is possible to translate it into a state diagram that will take many but many more sheets than the original drawing with the states well highlighted.
Regards
P.S.: I apologize for the imperfect English.
modified 24-Jan-23 6:09am.
|
|
|
|
|
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.
|
|
|
|
|
I have $1500 USD worth of items in circulation somewhere in the belly of UPS's logistics and transport system.
I have no idea where it is despite having a tracking number.
The product was shipped from Pennsylvania. The last update was January 19th, departing Pennsylvania.
It's expected Tuesday (tomorrow here). I'm betting I don't get an update until it arrives in Seattle at the very earliest.
What the heck is the point of giving out a tracking ID if it goes dark for 90% of the trip? 
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: What the heck is the point of giving out a tracking ID if it goes dark for 90% of the trip?
So noone can intercept it. Bravo Six, going dark.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Locally, UPS stands for "Ur Parcel Smashed": I've yet to see anything they deliver that doesn't look like it was used as a football. 
And if you think UPS tracking is poor, try UK Parcel Force - they just stay at "awaiting the parcel" until they switch to "delivered".
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I've had better luck with them thankfully. It's a video card, so it's kind of delicate. I'm a little anxious frankly, because the seller doesn't take returns. Nobody is on video cards right now.
To err is human. Fortune favors the monsters.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
