We handle the design of complicated algorithms by decomposition - breaking down the algorithm into component parts, and breaking those down in to simpler parts, until at the lowest level we can see exactly how to code the algorithms. Usually the decomposition is mirrored in the program structure by using subprograms. Hence, the problem of manipulating photographs into the modified forms displayed on this website (as in the Woodland Transformations Gallery for example) breaks down into top level steps as follows:
- Read photograph from a JPEG disk file.
- Loop until the program is terminated.
- Handle a control input (generally a key is depressed perhaps associated with a mouse position)
- Use the control input to modify the stored parameters that govern the image transformation algorithm.
- Transform the photographic image.
- Display the transformed image.
Each of these steps is implemented with a subprogram, but the "Transform" step, which is mathematically complex, is also broken down into a number of subprograms of its own, including an upper layer that handles the iteration of every pixel in the output image plane, and a lower layer that applies the a complex mapping algorithm to generate the pixel value at that point.
The professional software engineer is also trained to decompose information into hierarchical structures, and also to understand how relationships between different bundles of information can be accurately represented in software. This skill is not intuitive for the vast majority of people, and normally needs a good deal of practice to master. Few self-taught programmers bother to acquire this skill at the level of software professionals. Many do not even realise that they lack the skill.
What do we mean by this? Consider the compilation of an electoral register. In the UK voting rights go with residence. So, we need to compile a list of all places of residence - all valid addresses in the area covered by the Register. It is, however, people who have the right to vote, so we also need a list of people living at each address. To the software engineer, it makes sense to keep the list of people separate from the list of addresses and simply create an association between a person and an address. There are several reasons why this is a good idea. Firstly, people move but houses don't. (In general! Though new houses are built and sometimes old ones get knocked down.) If we simply create a list of individual electors each with their own address, then almost inevitably we will find that addresses are recorded inconsistently. (A computer does not necessarily know whether two addresses that differ only by commas, or spaces in postcodes are the same address.) If people move away and are removed from the Register, we would also loose any knowledge of the existence of an address, until the next residents fill out their registration forms correctly (perhaps!). Elections take place over a number of geographical ranges, from the most local Parish councils, town councils, county councils and national elections. An address that is associated with a ward in a local council will also associated with the county ward that aggregates the smaller scale electoral regions, and also refers up to the constituencies of parliamentary elections. It is therefore easy to build lists of electors for any level of election, and just as easy when electoral boundaries have to change to move whole groups of address from one area to another.