Random Ramblings on LabVIEW Design

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

Software Design an Electronic Design Analogy

Active Participant

Hello Data Driven Darlings

I've seen a few presentations that describe coupling and cohesion incorrectly and thought it might be an idea to revisit some material I have used in training before. I think all the talk about asynchronous processes (actors) also allows us to discuss the metaphor as well. 

Please note that this applies to all ways of designing software, using a methodology does not fix your coupling and cohesion issues. I've heard the statement "I use OOP and this gives me good coupling and cohesion" several times, only to be presented with a class full of references to other classes (Global Reference Object).

 

In our book we used an factory analogy and it worked OK. In a training course that we provide we use an electronic design metaphor and I think this might be a better analogy going forward.

 

First of all let's take a look at a simple electronic schematic and review cohesion

Cohesion – A measure of how strongly the elements within a module are related. The stronger the better. 

ElecSchema1.jpg

Our design task is to break this circuit into printed circuit boards (pcbs).

As a designer we could just split the schema like this and create 6 pcbs.

ElecSchema2.jpg

This is coincidental cohesion and I've seen it's use in LabVIEW by careless use of the Create SubVI function. Signs that you are suffering from this are:-

Lack of re-usable functions : the pcbs can only be used for this type of job.

Difficulty in naming : giving each pcb a name and purpose is difficult.

Difficulty testing : the pcbs can only really be tested when fully assembled.

 

We can easily improve the design by breaking out the functions of each pcb (functional cohesion). Here's a reasonable effort.

ElecSchema3.jpg

As a bonus we can see that the amount of inputs and outputs has been reduced. So improving cohesion also improves coupling too.

Improvements functional cohesion gives are :-

You can take some of these pcbs and use them in other pieces of equipment.

Testing should be simplified, because of clarity of purpose and simplified interface.

Pcb naming and functionality is nice and clear.

 

This is equivalent of a standard functional LabVIEW program, with nicely defined subVIs.

 

The next improvement would be to add a bit of complexity to our requirements. As an example let's take the PSU, I would like to be able to adjust the voltage and current, read-back the voltage and current, get calibration details and set calibration details. This can be done at board level with potentiometers, screens and an instruction manual. Alternatively we could have a messaging system to set and get parameters. This frees up our design from specific constraints and as long as the messaging interface is consistent the design details remain hidden. From our cohesive PSU pcb we are now considering coupling and how we can decouple (hide) design details from the overall design. This is information hiding.

 

Frees the design from specific implementations : just buy a PSU with the correct protocol, pop it in and away you go.

Change is easy to accommodate (if the interface is designed thoughtfully)

Design is simplified : we don't need to understand PSUs, we just need to know the interface.

 

Coupling - A measure of the degree of independence between modules. When there is little interaction between two modules, the modules are described as loosely coupled. When there is a high degree of interaction the modules are described as tightly coupled.

 

This describes LCOD/action engines/by ref objects pretty well. We have always called it component design.

 

This Eaton PLC system illustrates what we call component design quite nicely I think*.

EatonPLC.jpg

Each component in the system has a messaging system connecting everything together, each is a discrete component. The communications interface (SmartWireDT) allows additional features to be easily integrated.

 

So how do Actors fit into this analogy? I think we have to view an actor-based hardware system as a distributed system that can expand and contract to fit the problem at hand. One of the issues I have with it, is that I can't see that many real-world example that will need this extra effort.

 

Possible real world examples - Network of computers?? SCADA system where channels etc can be added automatically. Looking at large scale projects that use actor model languages we have messaging type applications (WhatsApp, Amazon and Facebook use Erlang mainly only where dynamic spawning is required i.e. dBs and connection management)

 

Hopefully cleverer peeps than me will fill in the blanks!

Off to Galway Ireland to speak at Dev Days next week (22nd June), should be fun! Say hello if you are joining us.

Le grá mór

Steve

* I've tried to improve the description of the component based system analogy (Thanks Mr Altenbach for the feedback)

 

 

 

 

Comments
Knight of NI

Nice post!

 

If you describe the extremes of coupling (loosely, tightly) followed by a sentence like: "This Eaton PLC system illustrates it quite nicely I think.". things become very ambiguous because we cannot tell which kind of coupling you are trying to illustrate with "it".

Active Participant

Can't say as I disagree Christian, I'll edit it in the next couple of days to clarify and expand the point.

Many thanks for your feedback, it's most appreciated.

 

Knight of NI

Ironically, I just finished a program that is running into issues because the circuit boards were not quite modularized properly.

 

One of the things I really like about being a Test Engineer is I get to see nearly all the aspects of engineering (a lot more than being an RF coop, a pure software engineer, or even a controls engineer).  And the more I see, the more I am convinced that good Software Engineering processes are no different (conceptually) than good general engineering processes (mechanical, electrical, etc).  I had a conversation last year with an RF engineer who bragged about how he could see all of his LabVIEW code in a single (very large) VI because he claimed he wanted to be able to see all of the details.  My mind went to his RF design diagrams where things were abstracted away (filter, amplifier, filter, pa, antenna instead of all the resistors, capacitors, inductors, transistors, etc).  So why treat code any differently?

 

So, Steve, I really like that you are showing software concepts as hardware concepts.  The parallels are not coincidental.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
Active Participant

Thanks Tim

Factory design and social design also have close parallels. I think there is a clear actor-oriented analogy (someone hopefully will say...how about such and such and it will all become clear)

Member

Thanks for the useful information.

Ian Bishop
Active Participant

No problem at all Ian and welcome to the blog.

Active Participant

Steve,

 

Another gem to your collection of great articles. At NI week you and I talked about how we have been finding all sorts of analogies between how the Delacor Hardware side of the house works with customers and how the Delacor Software side does it. We have been finding a lot more things in common, where, like Luis says, the only difference is that ordering a new PCB board is equivalent to getting to press the run arrow once and waiting 2 weeks to get the boards back.

 

I use the analogy with hardware when introducing Unit Testing in software. When customers call me to help them retrofit Unit Testing into existing code, they start complaining about not wanting to edit their code to fit unit testing better. I bring up the example where the test points for the test fixtures were not built into the original PCB board layout. It is really hard to add them afterwards, and no matter how hard we try, we end up doing a new layout, this time thinking where the test points for the test fixture fit. The same thing needs to be done to software. I also find that thinking about unit testing means that coupling and cohesion have to be addressed too, if something it is very difficult to test, more than likely it is trying to do too many things at once (not cohesive) or it needs inputs from a lot of different dependencies (tightly coupled to other units).

 

I also find that LCOD is not very different than Actor oriented design. The differences are in implementation. In LCOD, a component (also known as action engine) uses an enumerator to chose what "message" needs to be acted on. In Actor oriented design, an actor uses some messaging system to decide what to act on. The main difference, I think, is that components tend to be synchronous, we request the component to do something and wait for the response. Where actors tend to be asynchronous (although synchronous messages are possible, they are not the default messaging approach). 

 

I am looking forward to catching up with the rest of your articles that I have missed. 

 

Thanks again for sharing your wisdom with us.

 

Regards,

Fab

Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion
Active Participant

Thanks for your kind words as ever.

The original specification for LCOD was even more like Actors, but we wound it back for simplicity. I think the difference is not so much the asynchronous nature of Actors, any bussed system would fit that description. It's Actors spawning Actors that I can't get a solid equivalent for.

As you say the Design For Test movement was a real improvement on the hardware methods prior. Nowadays you have JTAG too, this is a specific communications protocol to test. I'm now beginning to use UDP to export program status data, which could evolve into a similar concept. You'll see more on this in a couple of articles time.