Modularity

The key to solving large problems well is modularity. This means dividing the problem into sections (or modules, components, blocks etc) and solving each section separately.

A program might be divided along the process flow (infeed, process 1, accumulation, process 2, outfeed, palletizer); by mode (manual, single-step, automatic, callibration); by levels (single motions, compound motions, actions, tactics, strategy); by purpose (control, monitoring, mmi, comms); or in some other way that makes sense for the project. It might well be divided by some combination of the above.

Often, a section is still too large to be solved in one piece, so it is divided into sub-sections in a similar way, and so on for the sub-sections.

The trick with modularity - and the reason why it's so important - is to ensure that each section does a single, well-defined job. It should interact with other sections sparingly; a sub-section should only interact within the section, unless its purpose is specifically interaction (in which case it should do little else). Obviously, like all rules, this can be broken on occasion. But not often.

$Date: 2004/12/28 05:32:12 $