Did you read the explanation in wikipedia?

http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design

The wikipedia page gives a good description.

However, to embellish on the matter a little bit, I find that a mix of top-down and bottom-up approaches can help identify weaknesses of each approach. In particular, where there are a lot of unknowns, or risks, a bottom up approach can force deeper exploration to reveal or mitigate risks.

As would be expected, when projects are very large it is impossible to work at a low level and consider the entire system in depth at once. Services, interfaces, and other larger components are extremely easy to work with at a higher conceptual level. Prior project experience can guide the selection of issues for lower level effort.

Without related project experience you can consider key elements that a developer or team of developers hasn't done before to be a risk item requiring low level analysis, design and possibly prototype development - generating knowledge and experience which can be brought into the fold later as the top-down effort gets to a suitable level.

The main thing here is about how you think: 

when you want to think top down you want to look from up and discrete the problem to some small parts and then solve them.

when you are thinking bottom up , you first solve the small parts from the first step without having a global view. just solve the problem step by step from small parts of it.

this is just my intuition from the topic, I hope it helps.

in top down programming (structured programming) you start by the problem and try to divide this problem into smaller problems and applying each solution (function or subroutine) to that problem so its from top (the main problem or program) to bottom (the smallest subroutine in your programming approach). on the other hand, bottom up approach is (object oriented approach) which an object is defined for the smallest possible entity in the program then these objects are linked and interacted together to form a solution this is why they called bottom up approach. hope this explanation helps

I like the architect/builder analogy offered above, but I'd take it a bit further. Bottom-up programming, if done well, involves designing proper building blocks and brick types and beams to support many different kinds of building. It results in more robust and flexible code. Pure top-down design will lead to a system that is possibly lean, but not necessarily flexible enough to stand up to changing requirements, or produce code that can be re-used in later projects. In my experience, you need a clear vision of the goal and a high level design (which can be developed top-down), and then build a robust library infrastructure bottom-up until the gap is so small that it can be easily closed. But there are different philosophies and experiences.

Hey ! Interesting question ! 

If we look at different program paradigms like :

Basic Programming

Modular Programming

OOP etc.,

there are few hidden differences. So if you look at a very normal program as follows :

#include

void main()

{

int a=1,b=2;

int sum=0;

sum=a+b;

printf("%d",sum);

}

when you execute this program, the execution starts from the main() function  and the control flows from top '{' to bottom '}'. So the flow of control is from top to bottom.

but if you take the following example : 

#include

int sum(int a, int b)

{

int sum=0;

sum=a+b;

return sum;

}

void main()

{

int a=1,b=2;

printf("%d",sum(a,b));

}

but in this example the execution starts from the main() function , the control flows from main() function's  '{' to sum() function's '{' then to sum() function's  '} then to main function's '}'. so if you observe the flow pattern it will be from bottom to top.

so basically the flow of control defines whether the program is using top down or bottom up approach.

Usually modular programming , oops follow the bottom up approach.

Hope it is helpful for you to understand :)

All the best ! 

I will answer this question based on OO methodology, because it will help students who are from non-programming background. OO looks at, say, for example who are involved, what are the inputs, output etc (refer to An Introduction to the UML and the Unified Process, Hunt 2009). Once you determine that then you start progressing, how will you use the objects and build a system so that it starts growing (from objects (at bottom) to may be a process (activity). Does it make sense? :-). 

In laymans terms, a top-down approach could be described as working with incrementally more detailed blue-prints of the system (similar to blue-prints of a building or bridge). The bottom-up approach is like starting with part of a bridge already built, then building on top of it.

For the top-down approach, initially, you would start with a very general blue print of what the system must do, maybe a few sentences describing what the system does and a picture with some labels.   Then using that first blue print as guidance and inspiration you would construct a second (more detailed) blue print.  This time with more specific information.  Then after that make another blue print and so on.   This would be done until you are confident that you've described the system so completely that the actual programming would be simple.  The reason you want to use blue prints when working top down, is that they are easy to reason about and make changes to. With real code, making changes is much more difficult.  

 Here are some analogies to make the concept more clear.  A stick person is a high level view of a person,  an actual photograph of a person is a low level view of a person.  A picture of North America from space is a high level view of America.  Placing your hand on the statue of liberty is a low-level view.  When working top down, you start with the high level view and add details until you get to the low level view.  

In contrast, The bottom-up approach is starting with details and working your way up to a complete system, in many cases, coding starts almost right away.   This is something often practiced in test driven development or when you prototype an idea.  Reasons why you might use the bottom up approach are that you might not know the problem well enough yet to describe it completely.   Or, there might be parts of the programming language your using that you don't yet understand, it would be difficult to use a top down approach in that case because you aren't sure about how to structure things because you aren't aware of the structure of the language its self.  

Usually a combination of top down and bottom up is used, depending on your experience.  A top down design and description of the system, followed by a bottom up, code and test of all the parts is what I find works best in projects where I know what must be built.  (This is referred to as the V-Model).   But that usually only occurs after several small prototypes are built.