If you follow this blog you would have been exposed to the term cohesion quite a lot and in computer science it is a means to group together related functionality. You would use it to help manage complexity in the modules of your system. In text based languages it could be as simple as grouping like functions in a library file. For SSDC we view the block diagram as our method of expressing the design logic and our methodology wants to group functionality in a single VI. Whereas other designers want that as a class, actor or DQMH module. All methods are striving to achieve this management of complexity. So far so simple.
For me there's always been a question mark against this definition and I now feel it is incomplete.
Let's look at a Oscilloscope as an example.
These VIs are all successfully doing one thing (mostly...), woohoo we have cohesion, jobs a good'un.
If you follow our LCOD design principles that's not enough, at some point we want to wrap these functions in another VI, because at some level of abstraction we don't care about initialising an oscilloscope, we just want to get a reading. An important benefit of doing this is that now we have an interface for our implementation to hide behind. This protects our software from changes below this level of abstraction. Simply put, we can change the oscilloscope type, but the software just gets a reading.
So what point is appropriate for moving from our NI-SCOPE palette VIs to a wrapper, it's pretty easy...we don't want to repeat calls to a NI-SCOPE palette VI in more than place.
And here it is being used.
So in summary here's a more complete definition of cohesion ...
A module should do 1 thing only and that thing should be appropriate to the level of abstraction.