Control Engineering

Link This | Email this | Blog This | Comments (1)

What are top-down and bottom-up design methods?
February 4, 2008

I first ran into the terms “top-down design” and “bottom up design” in the mid-1980s when working as a business systems analyst at radiopharmaceutical manufacturer New England Nuclear in Billerica, MA. At that time and in that department, there seemed to be some debate over which method was superior. As I remember, the system analysts advocated the top-down approach, while the programmers were rabid about working bottom-up.

To use the top-down method, the analyst starts with the big picture and works down to the details. The top level looks generally at what the prospective user wants the system to do and the major specifications. The analyst then works down a level at a time, filling in details until, at the very bottom, the design is complete.

For a software system, we’d start with a specifications list, then generate a top-level block diagram. We’d then work on each block individually, creating a next-level block diagram for it. The process keeps going, getting more detailed until ultimately we have a list of individual software modules. Some modules will likely already exist, some will be modifications of existing modules, and some will have to be written from scratch.

The bottom-up approach needs no clear picture of what the ultimate system will look like, but starts with one particular feature. Often, programmers start with a rudimentary user interface so that we can at least communicate with the system. The programmer then takes up another feature and writes a module for that, and adds “hooks” that connect it to the first module. Then, they test to make sure it actually does what it’s supposed to do. The process continues as the programmer takes up each feature in turn, creates a module to implement it, and integrates it into the growing system.

Managers, of course, love the top-down approach. With it, they know what they’re going to get, and can estimate overall costs and schedules. It also works well with the team approach, as there’s an overall plan of tasks that can be divided up between team members. The top-down method lends itself naturally to standard project management metrics, such as milestones, Gantt charts, bills of materials, and so forth.

The top-down approach does not, however, naturally create extensible projects. Adding or modifying features falls outside the normal top-down flow. Unless extensibility is explicitly made a feature, it is possible—even likely—that the resulting code will be so tightly integrated that later modifications are difficult.

Programmers, on the other hand, like the bottom-up approach because it gives them maximum creative scope. They don’t have to worry about the overall picture, because nobody knows what the overall picture is. The approach is especially efficient when the system needs to be expandable. Since the work naturally proceeds by adding features, adding new features at any time is not difficult. The resulting code is naturally extensible.

Bottom-up projects, however, are hard to manage. With no overall vision, it is hard to measure progress. There are no milestones. The total budget is guesswork. Schedules mean nothing. Teamwork is difficult, as everyone tends to work at their own pace and in isolation. The resulting code may not be well integrated because intermodule communication standards are ad hoc and tend to drift as the project goes forward.

Both approaches clearly have advantages and disadvantages. The good news is that they are not incompatible. The best approach is a hybrid: plan top-down and execute bottom up.

Start with top-down planning to identify required modules and interface standards. That makes possible all of the nice milestones, budgetary estimates, and task definitions project managers love. Stop short, however, of specifying how each feature or set of features is to be embodied. That would be what Lau Tsu called “cutting wood for the master carpenter.” The plan should provide enough detail so that everyone on the team knows what is expected of them, and can refer to standards that their efforts integrate seamlessly. It should stop at that point.

Don’t’ forget, however, to explicitly plan a means for making additions and modifications later on.

At that point, hand assignments out to the team members. They should then work bottom-up to generate the code. Well trained and disciplined programmers know how to use structured programming methods to modularize their parts of the project and avoid writing “spaghetti code,” which is difficult or impossible to maintain or extend.

The hybrid approach is easy to apply to other engineering projects. In fact, it is a natural way to do most projects in most disciplines.

Building any structure bigger than a doghouse, for example, is almost impossible to do any other way. How do you build a brick wall without knowing where to put it, and how many bricks to use? That’s the top-down part. When you take trowel and hod in hand, however, you’re going to put one brick on top of another from the bottom up.

Controls projects, however, could be done completely top-down or bottom-up. It is important for control engineers, therefore, to understand the two approaches and apply them appropriately in the hybrid approach. Even when an engineer is working alone, the hybrid approach helps keep the project organized and the resulting system useable, maintainable, and extensible.

The blog “Standard profits: Make2Pack and ISA88” covers many of these issues. 

Also read from Control Engineering: Building Trustworthy Software

Posted by Charlie Masi on February 4, 2008 | Comments (1)