Cohesion for VIs and your State Machine

[swatts]

Cohesion is a very important design consideration for producing decent software designs but are generally applied to VIs when talking about LabVIEW.

The types of cohesion that applies to modules (VIs), in order of the worst to the best type, are as follows:

Coincidental cohesion (worst)

Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together (e.g. a “Utilities” class).

Logical cohesion

Logical cohesion is when parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature (e.g. grouping all mouse and keyboard input handling routines).

Temporal cohesion

Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user).

Procedural cohesion

Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file).

Communicational cohesion

Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information, a “Waveform” class).

Sequential cohesion

Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data).

Functional cohesion (best)

Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (e.g. a PSU class).

I'd like the discussion to move onto how these rules can apply to States in a state machine. First I guess we should define a state machine.

A finite-state machine (FSM)  or simply a state machine, is a mathematical model of computation used to design both computer programs and sequential logic circuits. It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition.

In LabVIEW terms we may be looking at something like this.

Reading through the list above it can be seen that having clarity and purpose when defining states has the same advantages as when defining modules.

So how can cohesion apply to states in a state machine? One test I do for good cohesion of a VI is the "1 simple sentence rule".

1 Simple Sentence Rule

A VI should be described in 1 simple sentence.

With a state in a state machine I would modify to the following...

A State should be described in 1 simple sentence without logical connectives. (clue.. "Self-Test OR Test Units" is 2 states and the logic is part of the transition)

Another useful technique to consider is the granularity of the state, does it do enough to be tested.

We have worked on systems that drag states out of a database each state being a very small portion of a test. So for example each check on the results was an individual state. To do a test, get results, compare these results, print results and store them was in excess of 12 individual states in the state machine. The result was a system where it was very difficult to just do a test and get results, fault-finding was a pain.

The Yang to that particular Ying is if you have a state machine like this.

So although we can describe this in a simple sentence it's a bit disappointing. In this case the state is doing too much and any benefits of using a state machine are lost. If you find yourself making decisions and branching within your state code it's a pretty good sign that you need to break out some more states.

Localized cohesion (transitions in a state machine)

Localized cohesion is where transitions are generated near the state machine in the system architecture. This is similar to the UI equivalent of chunking and because of the visual nature of LabVIEW maybe something that applies to the block diagram too. There's a seedling of an important concept here.

So considering a state machine with transitions driven by a queue as shown earlier. We then spawn lots of concurrent processes and thoughtlessly allow any and all of them to trigger transitions, it can be seen that this will cause issues with comprehension (it's also an example of control coupling, of which I will talk about in another article). The simplest solution is to keep transition code within the state machine, obviously this is not so easy in some of the larger systems, but it should be a consideration in your design.

Another way to harm the cohesion of your state machine is with the event structure, for example it is very nice and convenient to put actions into your event structure when actually should you be firing off a transition instead? I'm framing this as a question because I'm about 80% convinced about this.

Some  oft forgotten states

Initialise State : Sets up your state machine.

Error State : We could report errors in here and make decisions about what to do next.

Safe Exit State : It's good to have a pigeon-hole where you think about how you safely exit your program. Especially true for control systems.

This is just the beginning of my thoughts on State Machine design, but I thought it would be useful to put the ideas out there as not a great deal is available on it barring the pure mechanics.

Lots of love and don't let your state machines get in a state!

Steve