Decision Table Based Methodology for Software Development (2004)
methodsandtools.com
methodsandtools.com
See also :
1) Hillel Wayne - https://www.hillelwayne.com/post/decision-tables/ and https://www.hillelwayne.com/post/decision-table-patterns/
2) Parnas Tables : A Practical Formalism (pdf) - https://cs.uwaterloo.ca/~jmatlee/Talks/Parnas01.pdf
3) Tabular Expressions and their Relational Semantics (pdf) - http://www.cas.mcmaster.ca/~wassyng/FIJanWas.pdf
Both have their strengths and weaknesses and, IMHO, the choice as to which to use is situational.
Another related technique which employs a bit of both of these approaches is the Visitor pattern[0].
If you don't need to codec through English there isn't much of a point. It's easy to work with ctrl-v'd spreadsheet formulas and hard to create a written narrative around them.
Disagree. The intent is to think through and write down the requirements unambiguously from problem domain so that it can be mapped easily to solution domain.
I agree on intent, and probably agree on usefulness, but I think my point was more that this is an older process from a time before instant and direct communication. I see it as introducing a layer of thought that doesn't need to exist if I can just ask someone from the source domain to send me their notes and walk me through them. We're probably using the same data format by now.
Again, I'm not saying the method isn't useful or appropriate, just that you won't see it as often now thanks to easier communication.
My mistake, i thought you meant "code" where you wrote "codec".
> my point was more that this is an older process from a time before instant and direct communication. I see it as introducing a layer of thought that doesn't need to exist if I can just ask someone from the source domain to send me their notes and walk me through them.
Not quite true. No amount of instant/direct communication can help in removing ambiguity from "normal" Human communication. You need to have a method which enforces rigour and precision in the communication technique. That's what Decision Tables and other formal/mathematical methods help you with.
The applicability of both in many problem domains remains a source of pleasant surprise to me to this day.
(a trie ain't nothing but a degenerate state machine)
On second thought, this is a wonderful hypothesis, because it would explain so much about the modern software environment...
As you add more states, you do not need to edit the existing states - well only the bits where you need to transition to the new state. This makes it much easier to maintain and reason about.
Each subsystem can be its own state machine too.
Made a menu selection? State Machine.
Interacted with a dialogue box/an HTML form? State Machine.
Used a dropdown/popup suggestions list? State Machine.
Written async code? State Machine.
Used a VM? State Machine.
Used a compiled executable? State Machine.
https://lamport.azurewebsites.net/pubs/state-machine.pdf
"safety" (nothing bad ever happens) and "liveness" (something good eventually happens) are two key properties for systems, and they both have easy formalisations in state machine terms.
Here is a brief introduction which may be of help:
https://www.cs.princeton.edu/courses/archive/spr06/cos116/FS...
A "State Machine" is a mathematical abstraction (i.e. a "computation" model) for the workings of a concrete machine i.e. A real Computer running a Program. When you start to write your programs as state machines you make its operations explicit, unambiguous and clear thus greatly reducing errors and guaranteeing "correctness". This is what makes it "essential".
I highly recommend studying Michael Sipser's Introduction to the Theory of Computation to understand this and other computation models (any edition will do).
The goal of software engineering isn't to make rules lawyers that implement the same logic as staff do only with less imagination and discretion. That's just a shortcut to reducing staff numbers while making worse decisions and reducing service quality.
The goal of software engineering should be to make systems that can support making better decisions. The rules your staff use today to figure out what flights should serve cocktails are themselves policies that evolved in service of some broader business goal, taking into account behind the scenes information like service costs, customer satisfaction, competitive analysis, brand intentions, etc.
Build software that supports that process.
If instead imagined to apply toward some of the complicated logic we regularly come across in actual computer programming, it starts to feel more useful. As programmers we've all come across cases of snarly boolean logic that nests multiple levels deep. In those cases, I've found decision trees very useful. I've taken it to the point of literally listing out every combination of conditions, rather than just the ones that seem to apply. Through that you can sometimes discover corner cases that need to be accounted for. Other times, you realize that you can collapse parts of the state so that your end-result conditional logic becomes much simpler. If you've ever had that case where you realized that your third-level internal condition could be moved to the outermost condition, thereby simplifying the code significantly, then that's what the exercise helps with.
The process of "requirements gathering" is by definition heuristic and iterative. The point of encoding it via "Decision Tables" (or any other technique) by a Domain Expert/Software Engineer is to be precise/rigorous so that it can be easily translated into computer code unambiguously.
The usage of the above will vary industry by industry depending upon their needs i.e. "Technical aspects" vs. "Social aspects". Thus a Nuclear Plant Manager/Aeroplane Pilot will be tightly confined within set bounds while Retail industry/Customer care will have a lot more leeway to consider the "Social aspects" involved. This can only be solved by "Human Resources Training" over and above Computer-aided support. The field of "Decision Support Systems" (https://en.wikipedia.org/wiki/Decision_support_system) is well established and supports a wide spectrum of both Computer and Human factors.
They are just another language, overtly verbose, with no opportunity for a clean presentation of your ideas, that convey the exact same information you encode on your code, and isn't any more clear to laypeople than code.
That stuff has some utility in a place or another, but if you are really thinking about making people fill one up, you should look into letting those people use a real programing language.