|
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.
|
|
|
|
|
Be glad it's not the USPS (US Postal Service)
Listen to this one:
Years ago sold an item on ebay.
Sent item via USPS and paid for tracking number.
The package went dark and I waited some weeks.
Finally went into post office where I sent the item.
The PostMaster General (manager) came out.
I explained that I had a tracking number and he poked around on his own computer in frustration trying to find it.
Finally, he looked up and said, "Do you see all those packages back there?" and pointed at a bunch of packages laying in the hallway. "We can't keep track of all those packages. It'll show up some time. Give it another week and if it doesn't show up, then come back."
They have one job. But apparently all USPS really does is make commercials trying to convince you that they can get your package there. 
The package did eventually show that it had been delivered.
|
|
|
|
|
Poste Italiane will simply open your package and steal the content if it's valuable.
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
|
|
|
|
|
OriginalGriff wrote: they just stay at "awaiting the parcel" until they switch to "delivered".
Strictly speaking, if that's reporting your status (as opposed to theirs)...it's not inaccurate, is it? I mean, you're either waiting for it, or you have it.
|
|
|
|
|
You'll received a "Delivered" confirmation without being delivered.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
FedEx and UPS are merging -> FedUp
Tracking on all carriers seems to be hit or miss lately.
PartsBin an Electronics Part Organizer - An updated version available!
JaxCoder.com
|
|
|
|
|
LOL
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
They generate EDI events only when your item checks in/out port, terminal, dry hub, local storage etc. In your case looks like your jem is traveling the Oregon Trail and will be no updates until it hits one of those. It's not like the truck driver is sending updates while on the road: "At the rest stop now. Smashed a bag of Wendy's and booked me a nice hooker. Life is good. lol!"
Advertise here – minimum three posts per day are guaranteed.
modified 23-Jan-23 9:29am.
|
|
|
|
|
I worked as a package sorter for UPS back in 1990. The package was probably placed in a trailer in PA and is driving across the country to WA. It won't get another scan until it is resorted in WA.
I had to learn blocks of zip codes and learn to read addresses backwards zip, state, city as my job. I would read that information and then place the package on the right belt to go to the other end of the facility. Got an extra dollar an hour for that skill. Had to take a test every month on a computer to verify sorting skills. Programming helped since I knew where the keys were. Other sorters had to use the cursor to the right place on the screen while I just typed the right letter for the zip code. I could sort 3600 packages an hour.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
Yikes, 3600 per hour sorted! amazing
Yes, shipping physically is quite different than shipping mentally
(which is what we usually do as customers)
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
That was just the test. The physical labor was about one package every 3 seconds or something like that.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
Is it better to have the situation I ran into? I had a package (64 GB of RAM) going from Dallas TX to Cincinnati OH. I got a lot of tracking data - I got to watch it go to most of the Rocky Mountain and Pacific Northwest states before finally heading to the Midwest (St. Louis, MO), then it took a side trip to Philadelphia before heading back to the St. Louis again. The final steps in the delivery to Cincinnati were from Indianapolis, IN to Columbus, OH, then to Louisville, KY (presumably passing through Cincinnati on the way!), back to Indianapolis, back to Columbus and then finally to Cincinnati and final delivery. The package was fine, but it took 2 weeks and close to 4,000 miles to get here. I did feel like I got my money's worth for the shipping cost, though!
|
|
|
|
|
Another Bill Bryson quote (I have collected lots of them!):
Goodness knows, incidentally, what my letter had been doing in California for nearly six weeks, though it came back with a nice tan and an urge to get in touch with its inner feelings.
(Notes from a Big Country: 'Mail Call')
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
