Community Nugget Series: Application Development- Installment 1

[JÞB]

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.

[Ben]

A couple of quick comments while the coffee starts to work.

1) Thank you for becoming a Nuggeteer!

2) Design first, code second - I like it!

3) I also use real life analogies as models when designing my applications. I approach the design challenge as if I am being asked to "get er done" 100 years ago when I did not have computers but had to to the job with people, actually dumb people, since computers are pretty dumb.

If I can come up with a model where I can walk through a scenario (in complicated apps I have acted the process out in the parking lot jumping back and forth between the personalities) using the dumb people and get the job done, then the job description for those dumb people become the specs for the components of the application.

So I am the same page!

Thanks again!

Ben

[JÞB]

On a minor side note:  Documentation- A clear consistant documentation style for VI info is important in good design and often overlooked!  I keep a series of files based on the attachment below ON MY DESKTOP and Quick-launch toolbar.  The VI properties>Documentation has a very poor interface for editing and this has been discussed many times in the Idea Exchange.  But a quick copy-paste from notepad makes a world of difference in ease of documentation.

A base doc template is attached for your enjoyment

[johnsold]

Jeff,

For the slightly smarter than fruit user who actually can read please use the spell checker in the text editor you use for preparing documentation.

Not "referance" but "reference."

I am looking forward to this series of nuggets. Ben said, "Design first, code second." I concur and am glad you started there.

Lynn

[_Ian_]

Jeff,

Good to see this - its the sort of thing I need and somehow never quite get around to putting in enough effort to educate myself properly. I've read your post a few times and have a pretty basic question:

Please could you (or anyone else) elaborate a little on the reasons for having both the Executive and Operations QSMs.

I think I understand the reasons for the Corporate Communications QSM (i.e. ensure the user always sees a responsive, meaningful interface) and the Accountant QSM (i.e. handling unexpected events, errors etc).

Within the company analogy I can see that the Admin department needs to be a different set of people to the Production department. However I would naively (and probably incorrectly) think that these two departments could be quite happily merged and co-exist when coding.

What am I missing?

Thanks,

Ian

[JÞB]

---

@_Ian_ wrote:

Jeff,

Good to see this - its the sort of thing I need and somehow never quite get around to putting in enough effort to educate myself properly. I've read your post a few times and have a pretty basic question:

Please could you (or anyone else) elaborate a little on the reasons for having both the Executive and Operations QSMs.

I think I understand the reasons for the Corporate Communications QSM (i.e. ensure the user always sees a responsive, meaningful interface) and the Accountant QSM (i.e. handling unexpected events, errors etc).

Within the company analogy I can see that the Admin department needs to be a different set of people to the Production department. However I would naively (and probably incorrectly) think that these two departments could be quite happily merged and co-exist when coding.

What am I missing?

Thanks,

Ian

---

Great points!  many of the functions CAN co-exist in code.  One state machine could run the entire project and we could choose a vastly divergent base and get the same tasking handled.  By NO MEANS is this series proposing that this is the only way to develop automated test. 

I intend the project to be approachable to many members of the community and am exposing some software design principals using this project as a vechicle to demonstrate "A good" design.  I chose an archietecture that will clearly diffferentiate the "Business Units" I layed the foundation for. 

[_Ian_]

I see! Looking forward to the next installments (I've just subscribed to the nugget thread in Breakpoint to make sure I don't miss the updates).

[JÞB]

---

@_Ian_ wrote:

I see! Looking forward to the next installments (I've just subscribed to the nugget thread in Breakpoint to make sure I don't miss the updates).

---

Great minds thinking alike: since I just posted the preliminarry sylabus for peer review

[F._Schubert]

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

[Ben]

---

@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