Talk:Top-down and bottom-up design

From Wikipedia, the free encyclopedia

Contents

[edit] Complete Utter Bull Dung

"Top-down programming is a programming style, the mainstay of traditional procedural languages, in which design begins by specifying complex pieces and then dividing them into successively smaller pieces. Eventually, the components are specific enough to be coded and the program is written. This is the exact opposite of the bottom-up programming approach which is common in object-oriented languages such as C++ or Java.

The technique for writing a program using top-down methods is to write a main procedure that names all the major functions it will need. Later, the programming team looks at the requirements of each of those functions and the process is repeated. These compartmentalized sub-routines eventually will perform actions so simple they can be easily and concisely coded. When all the various sub-routines have been coded the program is done.

By defining how the application comes together at a high level, lower level work can be self-contained. By defining how the lower level objects are expected to integrate into a higher level object, interfaces become clearly defined."

This is complete bull dung. Procedural coding can be done without defining one huge main procedure and dividing it into smaller subroutines. Many times a programmer thinks of small procedures and big procedures in different orders. Sometimes small little procedures are created first, to then work on a bigger procedure later. Similarly on object oriented hyped development, people will write small methods in their objects or big methods in not a black and white top vs bottom up way. In fact an object must be declared before use many times, forcing top down design instead of smaller little procedures in procedural coding. The object locks the design into the object early, whereas in procedural coding and modular programming one can rearrange his design without bonding it to a big heavily designed object.

This article sounds as though it comes straight from the OOP marketing hype department, and is void. The entire article is full of misinformation and bull dung.

In addition, methods of an object in Java, C++, modern pascal, are just procedures that have a hidden "self" parameter.

The article also made no mention of Modular programming and focused on OOP being the holy grail. I added some information about Wirth creating Modula to try and make the article at least a little more reasonable.

Another issue is real world examples.. the Windows API and the Unix API have been reused for decades, and are not developed using object methods.. but rather plain procedures. This just goes to prove that almost all DLL libraries and DSO/SO libraries out there coded in a procedural manner, are using bottom up or "reuse" style coding. In other words, the idea that traditional procedural coding is top down is ridiculous.. considering some of the Unix API's go way back to 1970 when procedural programming was popular and frankly it still is (modular programming and procedural coding are related).

Some of the most reused OS API's in the world are done in procedural and modular manner.. and there are far more "reused" operating system API's coded with procedures in modular manners, than there are OOP API's for OS's. OOP can be reused, and so can procedures... procedures can be bottom up and/or top down.. and so can objects.

The idea that OOP enables magical bottom up reuse where procedural programming doesn't is a complete utter hyped lie.

In fact the very definition of bottom up design and top down design is extremely vague and pretty much meaningless from looking at this article. LFiveZeroFive (talk) 23:00, 6 March 2008 (UTC)

[edit] Bottom-up-design discussion

I'd like to see mention of beginning the design of a system starting with the most technically challenging pieces and working down to the grunt work (the stuff that is "in the bag"). Many projects fail to take on the most challenging work and, after a lot of the easy stuff is done, come to a brick wall which cannot be overcome due to technical difficulties. That causes project failure,at last

[edit] Not just software

I wonder if we can rewrite this to make it non-software specific, and then move the software example into its own subparagraph. I think the concepts are useful in any sort of design, from game design to any other sort, no? For example, I randomly came here from International_auxiliary_language.--Sonjaaa 22:31, Nov 26, 2004 (UTC)

I agree we should rewrite this article to make it less specific. Top-down and bottom-up approches are actually very important concepts in nanotechnology and microelectronics too. Guillom 07:56, 23 August 2005 (UTC)
I agree too, but unlike Guillom, I think the issue is much more general than in microelectronics and nanotechnolgy - top-down design concerns engineering design in general, including mechanical, aeronautical, electrical, electronic, chemical engineering. Sangwine 15:19, 8 October 2006 (UTC)

[edit] Merge from 'Top-down programming' ?

These two articles were apparently written independently by authors who were unaware of each other's efforts. Chris the speller 18:26, 31 October 2005 (UTC)

I dont think that the two pages should be merged. top down and bottom up where pioneared by IBM for software design, These design techinques have been developed for software other areas may have taken them on but they still remain software design techinques at heart .

I disagree. See the section above about 'Not just software' - top-down design probably existed before software. It is an engineering design methodology, and software just happens to be one branch of engineering that uses it. Sangwine 15:21, 8 October 2006 (UTC)

Well, since the starting line of the article says it's about information processing, I believe programming can rightly take its place here. Moreover, programming is becoming more universal.

  • 1. Why do you know?
2. Why do you care?
3. Who do you think you are?
4. If you thought they should be merged why did you not do it yourself? —Preceding unsigned comment added by 212.219.57.50 (talk • contribs)
    • WP:NPA Your first three questions are invalid. On the fourth - while I didn't make the comment you're responding too, it's fairly common for people to ask about major merges and similar edits - a lot of information would be moving, some might be lost as duplicated, and especially it might be considered that any pair of articles that are merging might be unsuitable for merging for some reason. Compare in the same field the business and development articles for the Scrum process - while similar (and someone suggested a merge), they are not close enough for a merge. Someone going ahead and doing it themself would then be doing something that has now been discussed and by consensus resolved as two different things. That's a good reason not to just go ahead and do it. --Firien § 12:29, 30 August 2006 (UTC)

[edit] Examples of bottom-up programming

Right now, i cannot undertand how bottum-up designing is supposed to work. You always start a project with a rough plan which then is described more precisely. With bottom-up design, as it seems to me right now, you start developing something concrete, but actually don't know yet for what to use it ("oh, we just coded a program that can encode music very efficently, but don't know the heck where to use it"). --Abdull 14:03, 24 February 2006 (UTC)

Pure bottom-up design would probably be as you say ("oh, we just coded a program that can encode music very efficently, but don't know the heck where to use it"). You're correct that such a thing wouldn't work. A rough top-down plan would of course be drawn first. However, in pure top-down design it would be further refined smaller and smaller, whereas in a bottom-up plan you would jump to the bottom, solving small problems first and linking them together to solve bigger ones. For example, you'd decide that you want to make an game. From a top-down approach you'd decide exactly how you want the game to turn out, then break it down into smaller and smaller projects in order to realize that initial vision. With a bottom-up approach you might start working on a combat system, and you might start working on a story, and you might start working on the graphics, and then start fitting the pieces together and see what kind of game you're ending up with. TomTheHand 18:45, 24 February 2006 (UTC)
Hi TomTheHand, thank you for your quick reply! Your example really helped me getting an idea on how bottom-up design is supposed to work. Bye, --Abdull 00:32, 26 February 2006 (UTC)
In software and systems design, top down design is really intended for functional decomposition, not for the low level design. In reality I'm not sure that a pure top-down or bottom-up process exists in practice, or was ever intended as anything more than a concept of one extreme or the other. Requirements and design (and testing for that matter) always seem to push back on each other to some extent. That said, bottom-up design is not a model for designing something new or innovative. It is a reality however, due to the ecomony of common parts, reuse of code, the expertise of a detailed designer, and "constraints" (usually the word that someone uses when they ask for bottom-up design). Example: General Motors likes to manufacture a car (minus the powertrain) for 4 years to justify the high tooling expenses. They also like the powertrain to stay relatively stable for 4 years. But the powertrain is introduced into a car design that is two years old, and the new car is designed for a powertrain that is 2 years old. There are also some revolutionary designs, but many car platforms are evolutionary to avoid a complete shake up. So when the top-down guy is writing the requirements for the new chassis, he must take into account the powertrain that already exists. Likewise for the top-down guy that writes the requirements later for the powertrain. Bottom-up design results from a realistic compromise that always seems to creep into a top-down approach. 68.61.94.26 05:53, 9 November 2006 (UTC)

Seperate article for top down and bottom up development of countries etc. in geography needed.

[edit] What about nanotechnology?

This terminology is also used in nanotechnolgy as can be seen from this wikibook extract:

Top-down and bottom-up approaches

Top-down refers to the traditional workshop or microfabrication method where tools are used to cut, mill and shape materials into the desired shape and order. Bottom-up refers to methods where devices 'create themselves' by selfassembly. Chemical synthesis is a good example. Bottom-up should broadly speaking be able to produce devices in parallel and much cheaper than top-down methods, but getting control over the methods is difficult when things become larger and more bulky than what is normally made by chemical synthesis. Of course nature has had time to evolve and optimize self-assembly processes that can do wonders.

Shouldn't this be described as well?Hauberg 14:06, 23 October 2006 (UTC)

Nice find. I integrated some of this text into a new Nanotech section. Antony-22 21:47, 19 November 2006 (UTC)

[edit] "Top-down" and "bottom-up" disambiguation pages

Is there a reason "top-down" redirects here while "bottom-up" goes straight to the disambiguation page? Shouldn't they be made to be symmetrical? Antony-22 15:53, 21 November 2006 (UTC)