Community Nugget Series: Applicatio​n Developmen​t- Installmen​t 1

Question

Installment 1: Code by intention and basic code components
In
this Nugget series we will discuss application development, the
different ways we use to access data and information, develop a GUI that
has Controls, Indicators and other front panel objects accessable from
sub.vi's in multiple ways and explore a software developers approach to
LabVIEW without OO but exposing OO concepts. I'll be starting with
basics and moving to a real-world app designed specifically for Test
Automation.  Many of the concepts have wide ranging application but as
this is my first "Nugget" and "Series" I'll chose to speak from my
strengths.  I hope you all forgive me.
So lets show how to start:  I do it thusly
NOTE:
The vi hasn't even been saved yet!  The FP and BD are blank (OK - Use a
template if you want to save time but for this demo I'm starting from
scratch)
This is where software starts, with the end
user(s) firmly in mind!  <Sea Story> I grew up as an Electronics
Technician.  One day a test instrument rep demo'd a new o'scope with
advanced math functions.  We were impressed with the capabitities -
untill it took 5+ minutes to perform the operations.  Automate that!
[prompt user "please wait while device X does some math.  Ensure
sliptick oil resivour remains above "critical.""]   We called it "Same
Day Display."  The instrument MFG did not think about the end uses for
the product when archetecting the system.  <
Let's not do that here.  
Overall Achietecture: 4 main interlocking Queued P-C loop vi's
defined as: (If I may borrow from a business case to aid visualization)
Corporate Communications ( CC or GUI):
Executive:
Operations:
Accounting:
Each of these loops Consumes exactly 1 Queued loop:
1:
CC is primarrilly an Event Loop. After initialization it responds to FP
events.  These events can be caused by direct user action or by
indirect actions when something in the application generates an event
the GUI needs to respond to. It produces the "Executive" Queue and may
generate events.  It keeps the user informed and happy.   It is the
primary abstraction layer between the developer and the user.  If the
user can do it CC needs to respond - If the developer expects the user
to do something it Must be intuitive or explained by Tip Stips and / or
on screen instructions.
2: Executive is a QSM
(Queued State Machine) it consumes the "Executive" Queue, generates the
"Operations queue, and may generate events for CC.  This is the main
abstraction layer between the developer and the application
enviornment.  In this demo we will perform "Tests" defined as a sequence
of things do much like the tasks your manager asks you to take to
acomplish an objective.  Its the manager scheduling how when and what to
do and has a really great Admin department that knows the business,
what can be done by the Ops dept and has a list of activities that
should be performed to satisfy the customers (yep! sequence files!)
We'll get to those in another nugget in the series!
3:
Operations is another QSM it consumes the "Operations"
Queue, generates the "Accounting" queue, and may generate events for CC
.  This is the main abstraction layer between the developer and the
system components or HAL (Hardware Abstraction Layer).  All interaction
between the application and other resources (except the file system and
KVM) takes place here.  Again- we'll save that for another nugget.
4:
Accounting is another QSM it consumes the "Accounting"
Queue, generates "Executive" queue, and may generate events for CC . 
Its job is to let the Executive know what the result of the operations
are so managemant can make an informed desicion on what to do next. And
it files reports in whatever format the Admin assistant's policy says to
do it in.
Each of these four main functions exist in all applications and all LabVIEW code.  Here is CC GUI A.vi after saving 
the
GUI responds to user clicks of "stop"(Tip Strip Val ="Press to stop
this vi ") and the vi changes state on the next loop iteration.
Executive
functions are encapsulated in the while loop itself Management is
simple: "Unless the last operation was True do the same thing again" (and the constant 10 is our admin assistant!!!! change it and the app behaves different)
Operations
"list of things the vi knows how to do" is limited to Update i, Wait
(n)mSec and (AN,D not then, no data dependancy so we are multitasking!)
read Stop
Accounting is in the condition terminal reporting the value of
stop- and we chose not to report anything- could have reported Array of
Stop, Last i, or any of the values we see either to the FP, any file
whatever!  just illustrating a point.
Our requirements a a bit more detailed and we'll get back to the GUI next nugget:GUI FP object encapsulation.
Jeff

Answer 1

F. Schubert wrote:
Thanks for this nugget. The business case model looks interesting. I'm looking forward to see how this will evolve.
As a side note, I always like graphical sketches. So the basic idea of the interaction between the business entities could be drawn using boxes and arrows.
Felix
As ususal you and I are on the same page.
These images ...
and
appear im the documents I posted in this thread where I talked about doing the design first (consistancy).
The high level organizational, interaction diagrams are what I try to sketch up mentally during kick-off meetings. I use a variety of methods to get the information I need for these diagrams depending on what I know going in and the nature of the customer but... I don't let the meeting end until i have a picture tht models a system that meet the neeeds.
The diagrams doc what the customer wants, splits up the work into clean concise chunks, establishes responsibilities, needs, and the chararcter of each. In short they go a long way toward defining the design.
And for those apps you only up-date every three or four years...
There ain't nothing like those diagrams to gt you back into the same frame of mind you where when you designed it.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction