This is a specification and testing tool for software systems. It's based on the the Behavioral Programming modeling paradigm (think of it as the next-next generation of UML's State Charts, the next generation of the lesser-known Live Sequence Charts, or a sibling of TLA+). You can use it to model desired system behavior[1], visualize[2] and verify[3] it, and then generate optimized test suites to validate that the implemented application does what it was supposed to do. Test suites can be executed directly (using Selenium, REST apis, CLI integrations...), or exported as code/manual test books.
The model-based approach to specification and testing is very different from current specification and testing approaches, which are quite separate, are prone to ambiguities, and require a lot of manual work (especially test suite generation and test scenario maintenance). Using this approach, test scenarios and suites are derived from the model, so the work on test suite maintenance and composition is drastically reduced, model visualizations help even non-technical people understand what the planned behavior is, and verification ensures that the said behavior does not contain contradictions or violations.
Granted, this has been the promise of model-based software engineering for a long time, but this tool uses a different modeling paradigm and is created by software engineers, not mathematicians (insert evil emoji here).
The tool started as my PhD thesis project, but became useful-ish so we[4] decided to make it into an actually useful tool.
Looking forward to hearing what the HN community thinks of this!
----
[1] Technically, a large state machine/transition system defining desired interactions of the system-to-be with its environment.
[2] Yes, it's Graphviz, but with a lot of styling. Yes, there's a D3js version on the way.
[3] Actual formal verification of the model defined in [1].
[4] My PhD advisor, another professor from the lab, and yours truly
Yes. The tool does not support all of the BPMN standard yet, but within the supported range it can detect issues such as "process A happens before process B" or the like.
From what I can tell, I've built something similar, but a bit more niche, for industrial control and safety systems.
Though it lends itself to wider applications of state based behaviour.
It seems semi obvious to me this avenue is the path forward, not least because of the advantages that flow from having your specification as data, rather than dots on the page from a crappy narrative.
However, this approach does encounter some resistance because it is big work up front - you have to fully understand what you want to build, before you build it. It can look like little progress occurs for some time, but it all comes together much more quickly after specification is complete.
Very true. I think the upfront work required is the biggest resistance we get, along with "nah, I'm just gonna let some AI understand this for me" (can't help there, they'll have to find out for themselves :-)).
We alleviate this by allowing users to add details as needed - the underlying model does not require full description of the entire system, only the parts on which the current feature depends. This reduces the upfront work required and allows adding details later, on an "as-needed" basis. But sure, some upfront work has to be done.
Another resistance I sometimes get is that "people just don't think this way" or "I don't have anyone in the team that can understand the product AND the QA side". Did you get these too?
And worse, right through to experienced engineers telling me that I couldn't possibly specify all functionality this way, because the basic axioms are so small and few in number.
But when I have managed to implement this way, the amount of pain that does not appear in later stages of deployment is startling.
I have a uniquely frugal algorithm for execution of the state tables I generate, reduces down to a handful of logic operations, DM me if you are interested to discuss.
7 comments
[ 74.9 ms ] story [ 619 ms ] threadThis is a specification and testing tool for software systems. It's based on the the Behavioral Programming modeling paradigm (think of it as the next-next generation of UML's State Charts, the next generation of the lesser-known Live Sequence Charts, or a sibling of TLA+). You can use it to model desired system behavior[1], visualize[2] and verify[3] it, and then generate optimized test suites to validate that the implemented application does what it was supposed to do. Test suites can be executed directly (using Selenium, REST apis, CLI integrations...), or exported as code/manual test books.
The model-based approach to specification and testing is very different from current specification and testing approaches, which are quite separate, are prone to ambiguities, and require a lot of manual work (especially test suite generation and test scenario maintenance). Using this approach, test scenarios and suites are derived from the model, so the work on test suite maintenance and composition is drastically reduced, model visualizations help even non-technical people understand what the planned behavior is, and verification ensures that the said behavior does not contain contradictions or violations.
Granted, this has been the promise of model-based software engineering for a long time, but this tool uses a different modeling paradigm and is created by software engineers, not mathematicians (insert evil emoji here).
The tool started as my PhD thesis project, but became useful-ish so we[4] decided to make it into an actually useful tool.
Looking forward to hearing what the HN community thinks of this!
----
[1] Technically, a large state machine/transition system defining desired interactions of the system-to-be with its environment.
[2] Yes, it's Graphviz, but with a lot of styling. Yes, there's a D3js version on the way.
[3] Actual formal verification of the model defined in [1].
[4] My PhD advisor, another professor from the lab, and yours truly
Though it lends itself to wider applications of state based behaviour.
It seems semi obvious to me this avenue is the path forward, not least because of the advantages that flow from having your specification as data, rather than dots on the page from a crappy narrative.
However, this approach does encounter some resistance because it is big work up front - you have to fully understand what you want to build, before you build it. It can look like little progress occurs for some time, but it all comes together much more quickly after specification is complete.
We alleviate this by allowing users to add details as needed - the underlying model does not require full description of the entire system, only the parts on which the current feature depends. This reduces the upfront work required and allows adding details later, on an "as-needed" basis. But sure, some upfront work has to be done.
Another resistance I sometimes get is that "people just don't think this way" or "I don't have anyone in the team that can understand the product AND the QA side". Did you get these too?
But when I have managed to implement this way, the amount of pain that does not appear in later stages of deployment is startling.
I have a uniquely frugal algorithm for execution of the state tables I generate, reduces down to a handful of logic operations, DM me if you are interested to discuss.