Software Design an Electronic Design Analogy

[swatts]

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. 

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.

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.

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*.

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)