 |
|
Just Think About It! |
| Most of the
systems you deal with are
reactive. But most likely, they can have
something happening inside them even when they
are not processing messages received from
outside. Right? Moreover, most likely, they
consist of subsystems that are reactive too and,
in turn, can have their own "life", to an extent
independent from other parts (with which they
still communicate, of course). Such systems are
more naturally modeled with
active objects. So, why then should we try
to model and code them with GOOP and its passive
("dead"!) objects?
"Flat" State Machines have been known for
decades to have severe limitations. It's been
more than 20 years since Dr. Harel invented
hierarchical state machines (statecharts) to
fight those limitations. Then why should
we be stuck with the same old Moore automaton
still presented by some as the ultimate
tool for event-driven programming in LabVIEW™? |
|
 |
|
|
 |
A Simpler
and More Robust Way to Implement Non-Trivial Event-Driven
Applications in LabVIEW™
LabHSM is a professionally designed toolkit that
allows creating complex event-driven LabVIEW™
application
as an easily maintainable collection of
asynchronously communicating active objects
( actors ) based on a universal Hierarchical State
Machine
( HSM or statechart ) template. The
LabHSM toolkit enables the programmer to
work on a higher level of
abstraction and utilize agile software
development methodologies combining design and
coding in one highly flexible process. |
Version 1.1.2
for
LabVIEW 8.0 is available now.
 |
Fully functional in LabVIEW 8.0. |
| Complete with
block diagrams. |
| Simpler debugging code in
the full template. |
| Extra menu items in the editor to open VIs as well as HSM files - nice to have when the LabHSM
editor is the only VI open. |
|
Copying of default actions is now implemented
correctly. |
Download
it today!
ATTENTION! The Licensing scheme has been changed
starting from version 1.1.1.
| No
more run-time licenses! Just buy a developer's license
once and distribute as many applications as you like!
|
| The "Demo_" prefix is no longer required for VIs created
in the trial version. |
|
No more nag messages while running your HSMs! |
DO YOU WANT TO GET THE LabHSM
LICENSES FOR FREE PLUS FREE
IN PERSON TRAINING? HIRE THE AUTHOR!
Could your
company use
the services of a National Instruments Certified LabVIEW
Architect and NI Week winner
in the R&D/Lab Automation Category? Click here for resume!
SAVE AND
MAKE MONEY ON LABHSM - BECOME AN AFFILIATE!
The implementation basically follows
Dr.
Samek's Quantum Programming paradigm.
However, LabHSM stores the behavior information in a
file separate from the code itself. It also adds
state dependent priorities to events, a separate queue
for public events/messages, and, of course, some LabVIEW™
specific code like capturing front panel user events and
putting them into the private Events queue.
Communication and instantiation functions are also
rather specific for LabVIEW™.
The LabHSM toolkit
features:
|
Active objects
(a.k.a Actors) - much better and natural modeling of the
real life objects than traditional OOP objects. |
| Universal messaging system - post events to self, send
them to another object on the same system or across the
world. |
| Powerful
hierarchical state machine paradigm, free of
the limitations of a traditional, "flat" finite state
machine, namely, combinatorial state space explosion and
the lack of ability to consider the behavior logic on
different levels of abstraction. |
| All the information about behavior of an active object
is abstracted into a set of data structures and stored
in an external file - no spaghetti or deeply nested code anymore! |
| Design is code! Modified behavior becomes code
automatically as soon as the HSM file is saved. |
| A universal template provides code structure that stays the same
regardless of specific functionality. So all the code
has basically the same look and feel. |
| The diagram structure does not have to change
whenever you change the behavior. |
| Squeeze more functionality into your VIs without
creating more mess. |
| Code reuse within the same VI. The same segments of code
(actions) can be scheduled to run in different
transitions in a mix and match fashion, even more than
once in a single transition if desired. |
| Behavioral inheritance allows substates to define only
differences in behavior from their superstates. Inherit,
augment actions, or completely override in a substate
transitions defined in its superstates. |
| Transitions can be defined to lead to the target state
itself, its lowest default substate, or its history or
even deep history, which enables even more concise HSM
description (fewer states needed). |
| Ready to use external timer functions. Call a timer
creation function and let the timer send events to your
active object just like other regular active objects do. |
| Actions queue and a prioritized private Events queue
provide a Run To Completion execution free of
concurrency hazards. |
| A separate public Message queue to ensure encapsulation
principle is always observed. |
| A powerful specialized editor for creating and modifying
external behavior data files. |
|
|
|
|
