Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Thinking about Design Thinking

Active Participant

Hello Lovelies,

A couple of notices.

 

First, I've had a couple of presentations approved for NIWeek 2019 and they compliment each other, one is a reprise of my Immediacy presentation and the other is on Lean LabVIEW. I'm quite pleased with both of them and they will have new info in them (I've given the Lean LabVIEW one at a Developer Days and the Immediacy one at a European CLA summit). Hopefully you'll come say hello.

 

Second I had a spiffing time in Krakow with Prof Maj and all my CLA pals and some new NI Product Manager friends. It was great fun and Krakow was amusing and beautiful.

 

I've rescued a few jobs over the years and my #1 interest is what is going through the designers mind. Ploughing through another rescue job I had a small epiphany regarding design approaches and the differences in design approach.

 

Apparently there are 2 types of design Top-Down or Bottom-Up.

Top-Down

If you remember structured design you would define your system downward, gradually adding more and more detail.

 

TopDown.png

 

Bottom-Up

Whereas bottom-up is the reverse.

 

BottomUp.png

 

As you can infer from my flippant explanation I don’t really buy into it, but I do think some practices push programmers into designing in a bottom-up fashion. If you give an inexperienced programmer a list of requirements, you may find that they write a bit of code to fulfil requirement#1, another to fulfil requirement#2 etc etc.

 

Ticking off requirements is a bottom-up approach, whereas top-down view would dictate architecture to fit the requirements.

 

I've observed that thinking about Top-down or bottom-up is just plain wrong. You need to think about areas of risk, areas of certainty and areas you want to delegate responsibility. This should then drive your design decisions.

 

Areas of Certainty

Most pieces of code need some common functionality.. For us it's

  • Configuration
  • GUI Handling
  • State Machine
  • Error Handling
  • Exiting

These need to be easily modified.

 

This is where a framework would be handy and this can guide your top-down design.

 

Next you will have areas of certainty. As an example you will likely have some hardware specified. These can be defined, written and tested without more than a cursory glance at the customer requirements.

Examples are..

  • PSU
  • DAQ
  • Scopes
  • Reporting
  • Storage of Settings and Results
  • etc etc etc

Here you just need to offer a reasonable level of functionality, make it flexible enough and you may even have a re-usable component for your efforts.

 

This is bottom-up design.

 

Areas you want to delegate responsibility

Write an application for 4 scientists to use and they will give 4 completely different ways to solve the problem. This is when you need to design a system that pushes the decisions back onto them. This is where configurable systems are your friend.

 

 

Finally you will be thinking about UI design, State Machine design and every remaining bit of customer domain code. This will be a mixture of top-down and bottom-up. Abstractions will be Top-down.

 

So in this small example we've used such a mish-mash of top-down and bottom-up the only conclusion can be that these definitions are incorrect and probably unhelpful.

 

I believe the word "OR" in design is usually and indication that people don't fully understand the options.

So rather than thinking Actor OR OOP OR Functional, think Actor, OOP and Function where appropriate

It's not Events OR Queues, it's Events and Queues where you get advantages from each.

It's not Waterfall or Agile, use agile when the project requires it, use a stricter deliverable method for some of the internal system design work (i.e. stuff the customer doesn't care about).

Lots of Love

 

Comments
Active Participant

I find I tend to design top-down, but then code bottom up.  The messy part always seems to be in the middle where they meet.  Usually I find I never get this right the first time.  I usually have to do some refactoring there.

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
Active Participant

We define the different modules top down, then code each module bottom up. 

 

In my mind you need a destination of where the whole code is heading, then:

  1. you divide the work into smaller pieces (in the case of DQMH, that would be the DQMH modules)
  2. for each module, you define the communication between the modules
  3. code each module with a clear idea on how to test them individually (in the case of DQMH, that would be the DQMH API Testers)
  4. integrate all the modules and verify that the code arrives to the original destination
Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Proven Zealot

I'm with Fab and Sam on this one, define the modules with a top-down view i.e. what is is we need the code to be doing.

 

I also try to keep this top-down view in mind when doing the bottom-up implementations.  This way, the "meeting in the middle" problems Sam mentions can be sometimes nipped in the bud.  Also "Dependency Injection" is a great way of abstracting out the "what do we need done" (top-down) from "how do we do that" (botton-up).

 

Note: I'm mainly programming FPGA code

Active Participant

To do it completely top down you need a full set of requirements (or at least a decent set of requirements). This doesn't happen for us very often (if at all).

So I'll add this to the discussion - I think it's situational too....

As 2 examples below.

So if I was designing something in-house I would like go top-down (because I know the requirements), whereas if I had a customer that had a lot of kit already available I would probably go bottom up and start off with the hardware drivers. This would be initially much more useful to the customer.

 

 

Member

I feel like the proverbial frog in the well. Lived at the bottom initially, learnt enough to live comfortably with bottom-only programming. Then I started to wonder what is out there. Things became more difficult, but superbly interesting - design. Writing as a frog, I now read three steps worth, but seem to understand and implement at most one step.

One of the many things that flummox me - what exactly is the top? Is it the first VI invoked to launch the application? Is it the first user interface that the user sees? Is it the 'main' user interface that the primary user primarily interacts with? Is it all the UIs?

While still scratching my head bald with questions, I have started to appreciate Alan Kay's big idea about messaging. My thought process now somewhat follows what Omar Elgabry has blogged. I look for the verbs, the nouns (subjects, objects and instruments) of those verbs. Keeping those in consideration, I try to sequence the verbs and and associated objects (sequence diagrams crudely) to satisfy the highest priority feature(s) first. I then implement the code, tweaking both sequence and code, more the latter; until the feature works satisfactorily.

I guess my design approach is more 'upper middle' to top (to confirm user interaction); and then down to bottom.

Active Participant

Dhakkan,

I'm just going to say it out loud, I love the way you write!

You also get Kudos for linking to Alan Kay, he's one of our biggest design influences. Reading a book last week where it described the smalltalk view of objects (you send the object a message and the object internally runs its method) vs the C++ view (that and object has methods). I still prefer the smalltalk view and feel it maps better into computer/system language.

I'll read the links with interest.

Many Thanks

Proven Zealot

Smalltalk vs C++? I see no reason to have an overall preference nor make a choice at all. I see no contradiction in them happily co-existing.

 

For me it depends on what I want to do and also on which level of abstraction I'm at.....

Active Participant

I've managed to not use either in the last 20 years and am happy to keep it that way.

What was interesting to me was why I liked one over the other. Smalltalk is one of the most popular languages that no-one ever uses, so it's obvious which has "won" the popularity contest. Reading the book "The Problem With Software Why Smart Engineers Write Bad Code" (as recommended by James Mac) the author describes the difference in language design and how that affects the software designs written in them.

We have always described our components as objects that you send messages to and I've always found the method design in LabVIEW to cause my brain issues. It was nice to see it written out as over the years you forget your references.

Proven Zealot

Any other books on the subject which can be recommended?

Active Participant

I've not read one quite like this book, it's a harsh tear-down of the promises made in the 70's. Very well researched and referenced, probably worth going through some of the referenced material.