Hey All,
I'm writing medical software. In that end, I've come up with a workflow that allows me to show people with limited programming knowledge that the program I've made is the same as the program I was supposed to make. The workflow is the following:
1) Make a human readable document stating what the program must do, and what it must not do.
2) Convert that document into state machine diagrams.
3) Write unit tests that prove to be written C code implements the diagrams from step 2
4) Write code that passes the unit tests from step 3.
Step 1 and 2 can not be automated. I'm looking for a way to automate step 3 and 4. Basically I need some program that keeps the following statements in sync:
State machine diagram:
/** \page parallel_lcd
* parallel lcd state machine \n
* \dot
* digraph statemachine {
* node [shape=record];
* ST_LCD_INIT [ label="Init" , color = red];
* ST_LCD_INITA [ label="Init A" , color = red];
* ST_LCD_INITB [ label="Init B" , color = red];
*
* ST_LCD_INIT -> ST_LCD_INITA [ label ="(1)", arrowhead="open", style="solid" , color = green];
* ST_LCD_INITA -> ST_LCD_INITB [ label ="(2)", arrowhead="open", style="solid" , color = green];
* }
* \enddot
*/
Unit tests:
//arrow (1)
myLCD.state = ST_LCD_INIT;
parLcdExecute();
TEST_ASSERT_EQUAL_INT(ST_LCD_INITA,myLCD.state);
//arrow (2)
myLCD.state = ST_LCD_INITA;
parLcdExecute();
TEST_ASSERT_EQUAL_INT(ST_LCD_INITB,myLCD.state);
Code:
void parLcdExecute (void)
{
switch (myLcd->state)
{
case ST_LCD_INIT:
{
//do something
myLcd->state = ST_LCD_INIT_A;
break;
}
case ST_LCD_INITA:
{
//do something
myLcd->state = ST_LCD_INIT_B;
break;
}
case ST_LCD_INIT_B:
{
//do something
break;
}
}
}
I'm using the C testing framework "unity"
https://www.throwtheswitch.org/unityI've looked for state machine generators/compilers. I've found SMC: The State Machine Compiler, but as far as I can see it can't do what I'm trying to do:
http://smc.sourceforge.net/Does anybody know of software that can do this?
Cheers,
Cedric
I do not know any specialized software to do this task and that I have sometimes looked for.
When I have had to do something similar I have used Python and the Jinja2 templating language to manage source code templates.
If you have a clear idea of what you want to do, it's not too difficult to develop a macro yourself that translates state machine specifications into C code.
The state machine code should be in a more pythonic form, to reduce translation.
You can also look for Grafcet diagrams and Petri Nets. They are very similar to state machine diagrams, but more powerful and more implemented in PLC world.
Edit: You can also consider Sequential function charts (IEC 61131-3 standard)
You need to define clearly to all concerned the relative benefits of validation and verification. One is easy and boring; the other is interesting and difficult. One can be tested using TDD and unit testing, the other can't.
Ensuring "doing he thing right" is uninteresting. Ensuring "doing the right thing" is valuable.
You need to define clearly to all concerned the relative benefits of validation and verification. One is easy and boring; the other is interesting and difficult. One can be tested using TDD and unit testing, the other can't.
Ensuring "doing he thing right" is uninteresting. Ensuring "doing the right thing" is valuable.
Thank you for your reply. I have convinced everybody that making state diagrams and unit tests is important, and it has to be done.
But that was not my question. I am trying to decide if I have to write the program that keeps the state machine diagrams, the unit tests and the code in sync, or that that program already has been written. So far I think I have to write that program myself.
Cheers,
Cedric
You can also look for Grafcet diagrams and Petri Nets. They are very similar to state machine diagrams, but more powerful and more implemented in PLC world.
Edit: You can also consider Sequential function charts (IEC 61131-3 standard)
I think this makes a lot of sense. Just write it using a state machine language in the first place. This stuff was new about 15 years ago when I last did automation, but surely must be mainstream by now.
You need to define clearly to all concerned the relative benefits of validation and verification. One is easy and boring; the other is interesting and difficult. One can be tested using TDD and unit testing, the other can't.
Ensuring "doing he thing right" is uninteresting. Ensuring "doing the right thing" is valuable.
Thank you for your reply. I have convinced everybody that making state diagrams and unit tests is important, and it has to be done.
But that was not my question. I am trying to decide if I have to write the program that keeps the state machine diagrams, the unit tests and the code in sync, or that that program already has been written. So far I think I have to write that program myself.
"Kept in sync" could mean many things.
If you mean verify that C code matches the FSM, then you will fail. You would need to write something that parsed C code correctly (difficult) and then understood what it would do. That's equivalent to the halting problem.
If you mean autogenerate the unit tests, then that has no value. Either the autogeneration process is correct or not; if not then the tests are probably wrong too.
If you mean that C code is autogenerated from the FSM, there are many many tools that already do that. You must then ensure that the autogenerated C code is never modified; that would be equivalent to "patching the binaries"!
"If you mean that C code is autogenerated from the FSM, there are many many tools that already do that. "
Could you point me to those tools? I've looked in the wrong places.
Cheers,
Cedric
"If you mean that C code is autogenerated from the FSM, there are many many tools that already do that. "
Could you point me to those tools? I've looked in the wrong places.
Cheers,
Cedric
Whenever I need one, I just google for the latest and greatest.
Off the top of my head, here's a very old one:
http://smc.sourceforge.net/
Whenever I need one, I just google for the latest and greatest.
Off the top of my head, here's a very old one: http://smc.sourceforge.net/
Added to the
"stuff to check when I need a FSM again" list, thanks!
Do you happen to remember some other ones you have used in the past? Always handy to have a couple of candidates on standby, because tradition dictates the most suitable one for the project at hand is the very last one you check (out of a list of candidates). And yes, there is a 2nd order partial derivative of Murphy's Law that prevents you from picking N=1 for list size. Obviously.