Why VcaSde?

Back in the -80's, Object Oriented Turbo Pascal was a hot topic. Later we programmed in Smalltalk, Actor, C++, Eiffel, LabView, Java and C# to name a few. After learning OO concepts well, we where convinced that this was the Holy Grail for programmers.

Later, of course, we learnt that there is no concept or tool that provides the Holy Grail for programmers! Problem solving is a Divide and Conquer task: Divide the problem in small manageable problems and combine these solutions to Conquer the problem at hand. Indeed this is applied in most Algorithms.

We have found that State Diagrams seems to be programming language / tool / pattern agnostic: They provide a high level of Divide and Conquer and integrates well with most tools and patterns.

We have successfully used State Diagrams to structure code and execution in Real Time Control Systems and in our
HPC-09 v6 project.

Current State of the Art

Why VcaSde? We already have UML State Machines! Yes we have, and they are powerful: we have used them, as can bee seen here.

However, the power comes with complexity, especially if you use the more estorical features such as orthogonal regions. This complexity makes it difficult for the occasional user to maintain state machines. Also, the state machine diagrams are not guaranteed to be in synch with your code the way VcaSde State Diagrams are.

VcaSde Design Goal

We wanted to provide an easier to use yet powerful tool that both supported Windows and major smartphones through the Xamarin Platform. We also wanted to provide features not yet seen in the traditional tools:

E.g. when Starting an App using VcaSde State Diagrams, the App will transfer it's State Diagram to VcaSde Central where execution is shown and controlled.

Our VcaSde design goals:

  • Provide a Tool for Code Generation and Debugging (VcaSde Central)
  • Provide a small footprint (~60K) VcaSde Runtime providing Debug and Report capabilities.
  • All Features should be available on both Windows and the Xamarin Platform!
  • Keep the Visual simplicity of State Diagrams
  • Provide flexibility comparable of UML State Machines:
    • Support 5 State types: Initial , Final, Normal, Nested and SuperAbort
    • Support Parallell Diagram Execution in separate threads.
  • Avoid the State Machine complexity:
    • All 5 States follow the same basic design rules.
  • Guaranteed synch between Generated Souce Code & State Diagram:
    • No Round-Trip Engineering: The Diagram is by design the ground truth!
    • This goals is met by storing the Diagram in the Source Code (typically 60-80 K)
  • Over the Network (Wireless) Debugging of Diagrams both on Windows, Android and iOS.
    • App started in Debug Mode: App sends Diagram to VcaSde Central

We also developed what we called the State Diagram Context Pattern (*) showing an effective way to communicate between View and Model using the State Diagram as a Controller. State Diagrams can of course serve many other roles in a project.

(*) Not to be confused with the Java Context Pattern.

Geir Ove Skjaervik
Objective Technology