 |
|
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™? |
|
 |
|
|
 |
PLEASE READ THIS
FIRST:
As one can see in
the copyright line in the bottom of this page, this site was
created in 2004-2005 to promote LabHSM toolkit
for National Instruments LabVIEW
"system design" software. Please note: this had happened
long before NI created even its Statecharts
toolkit for LabVIEW, let alone their heavy push
for object-oriented programming much later and
implementation of Actor
Framework only very recently.
The only add-on product
for LabVIEW related to the concepts implemented
in LabHSM NI had then was a very primitive State
Diagram toolkit which did not support state
nesting (hierarchy). Despite the existence of
that toolkit, in their training materials NI
presented the most primitive Moore state machine
as THE state machine all developers should use,
not even mentioning Mealy.
The LabHSM toolkit used
a little of VI Scripting. It
had been already discovered by the developers
community in LabVIEW 7 because somebody at NI
forgot to password protect one of the VIs
shipped with it, but at that time NI had no
intention to allow the access to VI Scripting
for developers outside of the company. After
they tried to hide VI Scripting again
in LabVIEW 8 in 2005, the author restored the
access for the community with his
Property and
Method Selection Assistant.
Of course, today
the LabHSM toolkit by itself has not much value.
But the concepts and ideas which led to its
development remain very useful. In fact, they
are even more important today when
"applications
are deployed on everything from mobile devices
to cloud-based clusters running thousands of
multi-core processors. Users expect millisecond
response times and 100% uptime. Data is measured
in Petabytes. Today's demands are simply not met
by yesterday’s software architectures".
Therefore, I am actually happy that NI eventually
recognized that by implementing Statechart and
Actor Framework toolkits deeming LabHSM
obsolete.
The sole purpose
of putting this site back online today is for
the author to show to prospective employers one
of his contributions to the
LabVIEW programming field. So, only some
external references, contact info, etc. have
been updated. Otherwise, the site looks the same as it
did in 2005.
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
is available now!
Download
it today!
DO YOU WANT TO GET THE LabHSM
LICENSES FOR FREE PLUS FREE
IN PERSON TRAINING? HIRE THE AUTHOR!
Could your
company (US or Canada) use
the services of a National Instruments Certified LabVIEW Developer 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. |
|
|
|
|
