In article <1133504570.040973.12750@f14g2000cwb.googlegroups.com>, 
narkewoody@gmail.com says...
> i've already read though its feature list. but i still want to know
> your personal opinions.  how about the product and how you think about
> of using a WYSIWYG design tool in real life.
> 
> i personally prefer non-WYSIWYG tool.  for FSM, i like to write down a
> plain-text transmission table ( a matrix ) such as below,
> 
>    StateFrom StateTo  EventA/doFoo
>    ...
> 
> then have a tool draw any kind of graph for me, including postscript,
> pdf or jpeg.
> 
> by doing job this way i found i can easily maintain graphs and focus on
> core business problems without fussing on drawing and layout.
> 
> another benefit comes from version controlling. because the graph is
> plain-text and human readable, it is so much more easier than binary to
> be managed by a version control system such as CVS or Subversion.

It's no more difficult to version control than binaries.  Although I 
think a lot of these have move back to a textual representation.

> another question is about code-generating.  VisualState can generate
> code for a FSM.  in you opinions, how much benefits you can get from
> the capability ?  and what is the possible drawbacks ?  ( i always
> consider code-generating as pain for it introduces another kind of
> dependence into code )

I evaluated VisualState at one time.  I preferred BetterState's code 
generation (and a few other things) but I'm not sure that is even still 
available, if so it's certainly seems to be being kept quiet.  If anyone 
knows anything about it I'd like to hear.  Both systems have been updated 
since I did the evaluation and it wasn't as if one was bad and the other 
good they just had different approaches.

The big advantage I see to the visual layout of both products is the 
capability to easily see that all transitions are properly accounted for.  
Also I find transitions to and from nested states are much much easier to 
follow graphically than textually.

The biggest disadvantage I find is that both BetterState and VisualState 
are dongled.  A secondary disadvantage is that neither, the last I looked 
could have their code generation commandline driven so they are difficult 
to itegrate into a makefile or othe build environment.  Actually that's a 
criticism that can be levelled against a lot of these lower level case 
tools, they all seem to think that the world should revolve around them.

I did a set of test systems in BetterState once.  They ran from 30 to 90 
pages each as I recall each with somewhere between 2 and 5 or so states 
on them.  They worked quite well and I found them to be reasonably 
maintainable although the states really in many places were more of a 
flow chart.  I ws probably pushing the upper end of the size scale 
though.

Size of the generated code is not a problem generally although 
BetterState at one point insisted it needed malloc even when it wasn't 
necessary (that has been fixed).

I redid a set of interlock logic at one point, the code size was a little 
larger but it was also more complete.  

Robert

I have been using VS for about a year now, and I can't imagine going
back to manual.

I use it for the menu system on an embedded device. I did the last
project manually, but every time I had to make a change, it was
painful.  And the interaction of states was just getting too hard to
understand and manage.

I wouldn't bother with a smaller project, by I would hate to have to
implement my 12 page by 3 page drawing manually.

So far, the only thing I don't like is that if I am going to use a
variable internally, I have to define it internally.  I have a couple
of state-like indicators that I think should be defined outside VS, but
it won't let me if I'm going to make decisions based on them in the
state machine.  It's a pretty minor issue though.

BTW, VS now allows you to use "switch" if your compiler won't do a
pointer to function.


I used it and I liked it a lot.
It takes short time to get used with it but then you save a lot of
coding time.
It gives you a better view of your problem and at the end you have a
nice description (state chart) of your work which anybody can
understand.
The best benefit is when it comes to modify older code, you see the
chart, you don't have to read tons of code lines to understand what's
doing, just few mouse clicks and you are in.
I used it with RCS versioning control with no problem.
And, after all the generated code is much smaller being based on
look-up tables. Of course you can write your own code using lookup
tables but it will be very abstract and very hard to modify later.
I would say that this software lets you concentrate on how to solve the
problem not on how to implement the solving.

Of course, it is efficient for large state machines with many states.
If you have small state machines with just few states, don't bother to
use it.

Another nice feature is the use of hierarchical state machines. Again,
I know that everything can be done by simply writing code, but why
think on how to move from a state to another in text code when a simple
arrow, drawn with the mouse, can do this for you. And, if you change
your mind and want to jump to another state, just drag the arrow to it.

Your specification is also updated for free.

On 1 Dec 2005 22:22:50 -0800 in comp.arch.embedded, "Steven Woody"
<narkewoody@gmail.com> wrote:

>hi,
>
>i've already read though its feature list. but i still want to know
>your personal opinions.  how about the product and how you think about
>of using a WYSIWYG design tool in real life.

It's a good tool, but it's not a magic bullet.  It doesn't save you
from coding, the drawing _become_ the code.  But the "language" is
powerful and practical.

I used the Composer version 4.something.  It was a little clunky, but
quite usable, about on par with Visio.  Newer versions might be
better.

>
>i personally prefer non-WYSIWYG tool.  for FSM, i like to write down a
>plain-text transmission table ( a matrix ) such as below,
>
>   StateFrom StateTo  EventA/doFoo
>   ...
>

Over the past 20-some years, I've been intrigued by "graphical
programming languages," but generally unimpressed.  VisualState is the
only graphical programming tool that I feel is easier to understand
than code or pseudocode.

>then have a tool draw any kind of graph for me, including postscript,
>pdf or jpeg.
>
>by doing job this way i found i can easily maintain graphs and focus on
>core business problems without fussing on drawing and layout.

You might look at Samek's book on statecharts.  Some of his ideas
might help you go the other direction as well, to automatically
generate some of your code.

>
>another benefit comes from version controlling. because the graph is
>plain-text and human readable, it is so much more easier than binary to
>be managed by a version control system such as CVS or Subversion.

Agreed.  Managing different versions of the statecharts in VS is a
pain.  AFAIK, there's no plain-text output from VS to simplify
revision control.

>
>
>another question is about code-generating.  VisualState can generate
>code for a FSM.  in you opinions, how much benefits you can get from
>the capability ?  and what is the possible drawbacks ?  ( i always
>consider code-generating as pain for it introduces another kind of
>dependence into code )

Even back at V4, VS generated good, tight state machine code.  It uses
a sensible table-driven architecture with low overhead (I estimate
about 2K Flash on an HC908), and it's quite fast. And no manager ever
asked me to flowchart code written in VS. 

It does rely on the compiler supporting ANSI C, though.  One compiler
I tried to use did not support typedef of a pointer to function, so I
couldn't use it without hand-modifying the generated code.  I.e., I
couldn't use it.  At least not the generated code -- The statecharts
were done, so I mechanically translated them by hand.  A bit (or
more!) of a pain.

>
>any comments will be appreciated.

HTH,
   -=Dave
                                        -=Dave

-- 
Change is inevitable, progress is not.

hi,

i've already read though its feature list. but i still want to know
your personal opinions.  how about the product and how you think about
of using a WYSIWYG design tool in real life.

i personally prefer non-WYSIWYG tool.  for FSM, i like to write down a
plain-text transmission table ( a matrix ) such as below,

   StateFrom StateTo  EventA/doFoo
   ...

then have a tool draw any kind of graph for me, including postscript,
pdf or jpeg.

by doing job this way i found i can easily maintain graphs and focus on
core business problems without fussing on drawing and layout.

another benefit comes from version controlling. because the graph is
plain-text and human readable, it is so much more easier than binary to
be managed by a version control system such as CVS or Subversion.


another question is about code-generating.  VisualState can generate
code for a FSM.  in you opinions, how much benefits you can get from
the capability ?  and what is the possible drawbacks ?  ( i always
consider code-generating as pain for it introduces another kind of
dependence into code )

any comments will be appreciated.

-
woody