Top-Down and Bottom-Up Design

Top-Down  and Bottom-Up   Design:

Top Down Design

• We know that a system is composed of more than one subsystem and it contains a number of components. Further, these subsystems and components may have their own set of sub-system and components and create hierarchical structure in the system.
• Top-down design takes the whole software system as one entity and then decomposes it to achieve more than one sub-system or component based on some characteristics. Each sub-system or component is then treated as a system and decomposed further. 
• This process keeps on running until the lowest level of the system in the top-down hierarchy is achieved.
• They allow us to quickly and efficiently specify, design, synthesize and verify designs ready for fabrication. The key to these methodologies is synthesis, which relies on a mapping between the logical functions we use in a design and the physical circuits that realize the functions.

Characteristics of Top-Down Design:

• Top-down design can be perceived as visionary. Because top-down designs are not constrained by current work practice, they can turn out startlingly different and even futuristic designs, which shows how top-down design can be visionary.
• Top-down design is heavily driven by domain knowledge. Designers need extensive domain knowledge to be able to abstract the nature of work in that domain. This usually translates to the need for designers to envision multiple work activity instances in that domain.
• Being a potential user in the domain is good for a designer

Bottom-up Design

• The bottom up design model starts with most specific and basic components. It proceeds with composing higher level components by using basic or lower level components.
• It keeps creating higher level components until the desired system is not evolved as one single component. With each higher level, the amount of abstraction is increased.
• Any design method in which the most primitive operations are specified first and the combined later into progressively larger units until the whole problem can be solved: the converse of TOP-DOWN DESIGN. 
• For example, a communications program might be built by first writing a routine to fetch a single byte from the communications port and working up from that.
• Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the basic primitives can be used in the newer system.
• Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is used.

Top Down	Bottom Up
A module cannot be tested in isolation because they invoke some other modules. To allow the modules to be tested before their subordinates have been coded, stubs simulate the behavior of the subordinates.	It starts from the bottom of the hierarchy. First the modules at the very bottom, which have no subordinates, are tested. Then these modules are combined with higher-level modules for testing. At any stage of testing all the subordinate modules exist and have been tested earlier.
Here,we start by testing the top of the hierarchy and we incrementally add modules that it calls and then test the new combined system. This approach of testing requires stubs to be written. A stub is a dummy routine that simulates a module.	Drivers are needed to set up the appropriate environment and invoke the module. It is the job of the driver to invoke the module under testing with the different set of test cases
Targets given by executives	Executives set the direction and define the mission
Long execution time	Short execution time
More stable and accurate at the aggregate level	Higher accuracy at the granular level.