The Lounge - CodeProject

First Prev Next

Re: Reverse engineering - flowchart ?

charlieg23-Jan-23 11:29

charlieg

23-Jan-23 11:29

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.

Re: Reverse engineering - flowchart ?

giulicard23-Jan-23 23:41

giulicard

23-Jan-23 23:41

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.

Re: Reverse engineering - flowchart ?

rjmoses24-Jan-23 3:21

rjmoses

24-Jan-23 3:21

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.

Adventures with UPS

honey the codewitch23-Jan-23 2:14

honey the codewitch

23-Jan-23 2:14

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? D'Oh! | :doh:

To err is human. Fortune favors the monsters.

Welcome to the Lounge