Emery Scale AF Solution from CLA Group

[CaseyLamers1]

2015-06-15 10:17 AM missed a method for Zero Coupling. Added it in about 5 min.

2015-06-15 Updated to have "Zero Coupling" took about another 30 minutes.

2015-06-22 Created a Publish Subscribe version where the zero coupling works such that the controller doesn't know about the UIs that are attached to it. This is a use case more similar to a bank. Took 2 hours.

***************************

This is the AF version of a discussion around frameworks and difficulty from the Certified LabVIEW Architects group. I have posted here for inclusion of individuals that are not members of that group.

The Emery Scale is

This project took me about an hour to write from reading the requirements to having it zipped up and ready to post. I am an expert in AF. I have been using AF for 3 years. For quickness I did not create a "Zero Coupled" solution. That gave me some pain (because I believe strongly in using that style), but I could refactor to add it in probably 10 minutes.

There is a saved for 2013 version included, but I have not tested it and apparently you need 2013 versions of 2014 AF VIs that can be gotten HERE.

Casey

******************************************************************************

Here is the CLA group text describing the project

******************************************************************************

The attached presentation is the slide deck and source project that I presented at the CLA Europe summit in 2015.

The thrust is about our responsibility to bring CLAs like myself who don't do architectures every day up to the level that the more experienced CLAs are at - there's a chasm that needs bridging and hopefully the project and documentation can be referred to to hililght that whilst learning say the actor framework as an example is possible, it loses a lot for a novice to debug with, and therefore it's seen as both advanced and an evolution as opposed to an option that we could choose to use.

It also serves as a roadmap that needs populating with other framework implementations including user stories (DQMH and State machine objects and LCOD to name an initial 3)

Having received lots of feedback after the presentation, I propose this has a place being extended for what Jack Dunaway was coining the phrase the "Emery's Scale" which would be verified by Steve Watts and Jack's side discussion on function point analysis for complexity beyond things like DSQI.

We're still trying to define exactly what that means, but it's relative to a figure of merit of how comprehensive an architecture is required as a minimum to achieve the end project and matching the scale value (principally 1-7) to existing frameworks based on what they offer and how hard they are to learn and use,

If you have comments, please please please share below.

I'm also going to update this with a proper requirement document on what is required for anyone to create an example in their framework of choice to make the "simple" and "extended" ATM pieces and how to rate themselves on the scale.

Watch this space (which may move location), but for now, any comments welcome!!

Yay - 5 mins to myself.

Let's have a stab at the requirements for this thing - essentially a FizzBuzz as Steve pointed out but much more LabVIEW aligned....

Note the use of the word implementation here - this can be done as procedures rather than actual automating code. For example..

The first example in the .zip is a flat VI and if we wanted to make multiple UI, then the implementation would involve a copy and

paste at the Windows Explorer layer and then manually launching the new copy. Of course that means data sharing so cheerfully use a global or a file.

1a) The implementation must show the principle of the framework or architecture (what makes it unique to other frameworks / architectures) either implicitly or through documentation.

          (my loose definitions are frameworks are hidden necessary structures that we build upon and architecture is something visible for all to see)

1b) The implementation must show the principle of expansion within the framework or architecture either implicitly or through documentation.

1c) The implementation must include documented time to develop the initial revision and the time to develop the expanded revision.

1d) The implementation must document any available reference material for learning the framework or architecture used.

1e) The implementation must document the perceived level of familiarity with LabVIEW required to be effective with the framework or architecture. For example, LabVIEW core I and II with 3 months developing stand alone Windows applications.

1f) The implementation must document the perceived benefits and drawbacks of the framework or architecture implemented.

1g) All source code must be documented in combination with the framework / architecture documentation to provide a guide for people examining the code base. For example, inside a block diagram it may reference a #Reference_3 bookmark which is referred to in the accompanying guide documenation.

1h) An estimation of code complexity must be documented on a scale of 1-7 where 1 implies a simple implementation that protects from expansion, and 7 implies practically all the implementation is dedicated to expansion. For example, the single loop with event and a global variable would be a 1, and Actor would be a 7.

2a) The initial version (referred to as VI1_x where x is an instance number) must allow for the following behaviour

          i) Present 4 buttons to the user named Deposit, Withdraw, Query and Stop.

          ii) Present one floating point number control to the user

          iii) Present one floating point number indicator to the user

2b) The intial version must allow for a number to be stored and modified and queried as follows

          i) On creation of the first instance (VI1_0) of a user interface, the stored value must be initialised to 0.0

          ii) The Deposit button must add the value in the floating point number control (2aii) to the stored value and store it back. E.g. if the stored value was -12.0 and the control contained 5.0, then pressing deposit would store the number -7, overwriting the previous value of -12.

          iii) The Withdraw button must subtract the value in the floating point number control (2aii) from the stored value and store it back. E.g. if the stored value was -12.0 and the control contained 5.0, then pressing deposit would store the number -17, overwriting the previous value of -12.

          iv) The Query button must read the stored value and display it in the floating point number indicator to the user.

          v) The Stop button must stop and close all currently open instances of the first implementation.

          vi) Stopping may also close a user interface implementation.

2c) The initial implementation must demonstrate multiple visually identical copies of the user interface existing at the same time such that...

          i) Pressing deposit on VI1_1 (stored value 10.0, control set to 4) and then withdraw on VI1_2 (control set to 5.0) followed by query on VI1_0 would result in a value of 9.0 being displayed in the indicator of VI1_0

          ii) The implementation will only support atomic activity such that the stored value is dealt with in its entirety before the next activity regardless of the instance that requested the activity.

3a) The expanded implementation (referred to as VI2_x where x is an instance number) must allow for the following behaviour

          i) In addition to the capabilities listed in 2), the user interface must have a unique colour to differentiate it from the initial implementation user interface

3b)  The expanded implementation must demonstrate multiple visually identical copies of the user interface existing at the same time such that...

          i) The mechanism for deciding whether to launch an initial implementation user interface or an expanded one must be demonstrated either with code or documentation.

          ii) Pressing deposit on VI1_1 (stored value 10.0, control set to 4) and then withdraw on VI2_1 (control set to 5.0) followed by query on VI1_0 would result in a value of 9.0 being displayed in the indicator of VI1_0

          iii) The implementation will only support atomic activity such that the stored value is dealt with in its entirety before the next activity regardless of instance and version that requested the activity.

          iv) The Stop button must stop all currently open instances of the user interface regardless of which implementation they came from.

4a) It is up to the implementation how to launch new user interfaces

          i) one additional user interfaces may be createed. For example, this could contain a launch button and a revision selector.

Please comment - I've bound to have fouled up the requirements, and yes, I know a lot of them are UI related and not strictly UTF implementable....

[drjdpowell]

For quickness I did not create a "Zero Coupled" solution. That gave me some pain (because I believe strongly in using that style), but I could refactor to add it in probably 10 minutes.

I think you should do the "Zero Coupled" solution.  This isn't a simple example for novices, but something that gives a flavour, for other CLAs, of what you would actually do in a real app. 

[drjdpowell]

Much better.  Your combined time is still beating mine, though

[Oli_Wachno]

Casey, thanks for this example...

It makes me think over my far more complicated Zreo Coupling messaging.... What I thought I saw when experimenting was that if you send an Abstract Message to an Actor featuring a child implementation, the child implementation was not called, but instead the Do.vi implementation of Message.lvclass.

Seems, I have to re-check, especially referring to https://decibel.ni.com/content/docs/DOC-37533

EDIT: Found, where I went wrong, did not take the initialisation of UI-Actor into account

[CaseyLamers1]

I looked at the example (even after you had things crossed out) and I think there is a difference between how I do it and how Jon did it.

Jon's example has the zero coupled data in the root actor.

My example has the zero coupled data in the nested actor.

I think there are excellent use cases for both.

***********************

Read if interested...

I generally have a 3 level system (system, subsystems, components). I reuse components all the time. They send data to the subsystems. The subsystems "know" about the component. The component only knows that it was launched by something. So I use the zero coupled data in the component and when I launch it I give it the subsystem "child" message.

I was partially underway writing it so that the UIs would have a child of the cotroller data message. They would send their Q and the child data message to the controller. The controller would keep track of the registered Qs and their individual reply messages in 2 arrays.

I am not sure which way would be best "in real life". Probably good use cases for each.

When I have another hour I will code it up.

Casey

[Oli_Wachno]

Yeah, it seems, my solution is a bit more complex / complicated.

I have defined the abstract message classes in a dedicated lib, each Actor has its implementation if the message is supported.

I'm using a strictly hierarchical architecture, so I can use the following approach:

if a SubActor gets launched it sends the supported message objects to the invoking actor. These are stored in a table. If a message is to be send to a subactor, the according object is retrieved from the table and the actor receives the correct class.

I'm having a presentation on the abstract messaging topic in autumn during the German VIP Days. Until then, I'll have some pictures ready to explain this a little more clearly

[Jeannius]

I just wish that some of those High level CLA discussion was available to advance non CLA, people with extensive programming experience but still new-ish or not CLA in LabView.

I would love to see some of those frameworks.

[Sash]

Hi Jeannius,

  yep - this is why we're trying to do this - so far there's a set of frameworks to implement the same task (as described above) which should be easy enough for people to get their head around - the harder part is saying the pros and cons of different approaches and uses of people's favourtie "hammer" to crack the problem with.

The reason it refers to the EmeryScale is a phrase coined in a presentation I did where I had 7 examples and it looked like I was rating the complexities and benefits of approaching the same problem with different hammers.

Once this is more fleshed out, I'll be sharing it to the wider community.

For now, I'll send you what I did so far as a starting point - hopefully it will give some pointers.

Thanks