Content: Top-down Approach Vs Bottom-up Approach
Show
Comparison Chart
Definition of Top-down ApproachThe top-down approach basically divides a complex problem or algorithm into multiple smaller parts (modules). These modules are further decomposed until the resulting module is the fundamental program essentially be understood and can not be further decomposed. After achieving a certain level of modularity, the decomposition of modules is ceased. The top-down approach is the stepwise process of breaking of the large program module into simpler and smaller modules to organise and code program in an efficient way. The flow of control in this approach is always in the downward direction. The top-down approach is implemented in the “C” programming language by using functions. Thus, the top-down method begins with abstract design and then sequentially this design is refined to create more concrete levels until there is no requirement of additional refinement. Definition of Bottom-up ApproachThe bottom-up approach works in just opposite manner to the top-down approach. Initially, it includes the designing of the most fundamental parts which are then combined to make the higher level module. This integration of submodules and modules into the higher level module is repeatedly performed until the required complete algorithm is obtained. Bottom-up approach functions with layers of abstraction. The primary application of the bottom-up approach is testing as each fundamental module is first tested before merging it to the bigger one. The testing is accomplished using the certain low-level functions. Difference between Bottom-Up Model and Top-Down Model
Top-Down Design Model:
Advantages:
Bottom-Up Design Model: Advantage:
Article Tags : DBMS Difference Between Practice Tags : DBMS Product design and developmentEditDuring the design and development of new products, designers and engineers rely on both a bottom-up and top-down approach. The bottom-up approach is being utilized when off-the-shelf or existing components are selected and integrated into the product. An example would include selecting a particular fastener, such as a bolt, and designing the receiving components such that the fastener will fit properly. In a top-down approach, a custom fastener would be designed such that it would fit properly in the receiving components.[2] For perspective, for a product with more restrictive requirements (such as weight, geometry, safety, environment, etc.), such as a space-suit, a more top-down approach is taken and almost everything is custom designed. Computer scienceEditSoftware developmentEditPart of this section is from the Perl Design Patterns Book.In the software development process, the top-down and bottom-up approaches play a key role. Top-down approaches emphasize planning and a complete understanding of the system. It is inherent that no coding can begin until a sufficient level of detail has been reached in the design of at least some part of the system. Top-down approaches are implemented by attaching the stubs in place of the module. This, however, delays testing of the ultimate functional units of a system until significant design is complete. Bottom-up emphasizes coding and early testing, which can begin as soon as the first module has been specified. This approach, however, runs the risk that modules may be coded without having a clear idea of how they link to other parts of the system, and that such linking may not be as easy as first thought. Re-usability of code is one of the main benefits of the bottom-up approach.[3] Top-down design was promoted in the 1970s by IBM researchers Harlan Mills and Niklaus Wirth. Mills developed structured programming concepts for practical use and tested them in a 1969 project to automate the New York Times morgue index. The engineering and management success of this project led to the spread of the top-down approach through IBM and the rest of the computer industry. Among other achievements, Niklaus Wirth, the developer of Pascal programming language, wrote the influential paper Program Development by Stepwise Refinement. Since Niklaus Wirth went on to develop languages such as Modula and Oberon (where one could define a module before knowing about the entire program specification), one can infer that top-down programming was not strictly what he promoted. Top-down methods were favored in software engineering until the late 1980s,[3] and object-oriented programming assisted in demonstrating the idea that both aspects of top-down and bottom-up programming could be utilized. Modern software design approaches usually combine both top-down and bottom-up approaches. Although an understanding of the complete system is usually considered necessary for good design, leading theoretically to a top-down approach, most software projects attempt to make use of existing code to some degree. Pre-existing modules give designs a bottom-up flavor. Some design approaches also use an approach where a partially functional system is designed and coded to completion, and this system is then expanded to fulfill all the requirements for the project. ProgrammingEditBuilding blocks are an example of bottom-up design because the parts are first created and then assembled without regard to how the parts will work in the assembly. Top-down 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. 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 ready for testing. By defining how the application comes together at a high level, lower level work can be self-contained. By defining how the lower level abstractions are expected to integrate into higher level ones, interfaces become clearly defined. In a bottom-up approach, the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a "seed" model, by which the beginnings are small, but eventually grow in complexity and completeness. Object-oriented programming (OOP) is a paradigm that uses "objects" to design applications and computer programs. In mechanical engineering with software programs such as Pro/ENGINEER, Solidworks, and Autodesk Inventor users can design products as pieces not part of the whole and later add those pieces together to form assemblies like building with Lego. Engineers call this piece part design. In a bottom-up approach, good intuition is necessary to decide the functionality that is to be provided by the module. If a system is to be built from an existing system, this approach is more suitable as it starts from some existing modules. Parsing is the process of analyzing an input sequence (such as that read from a file or a keyboard) in order to determine its grammatical structure. This method is used in the analysis of both natural languages and computer languages, as in a compiler. Bottom-up parsing is a strategy for analyzing unknown data relationships that attempts to identify the most fundamental units first, and then to infer higher-order structures from them. Top-down parsers, on the other hand, hypothesize general parse tree structures and then consider whether the known fundamental structures are compatible with the hypothesis. See Top-down parsing and Bottom-up parsing. module add4 (s,c4,ci,a,b); input [3:0] a,b; input ci; output [3:0]s; output c4; wire [2:0] co; add a0 (co[0],s[0],a[0],b[0],ci); add a1 (co[1],s[1],a[1],b[1],co[0]); add a2 (co[2],s[2],a[2],b[2],co[1]); (adsbygoogle = window.adsbygoogle || []).push({}); add a3 (c4,s[3],a[3],b[0],co[2]); endmodule
Examples of instantiation // NOT Gate logic simulation `timescale 1 us / 10 ns module inverter(IN,OUT); output OUT; not #(1,3) inv1(OUT,IN); // gate instantiation endmoduleNote: not is a verilog-provided primitive //NAND Gate simulation model `timescale 1 us / 10 ns module nand_gate(IN1,IN2,OUT); input IN1,IN2; output OUT; // gate instantiation (adsbygoogle = window.adsbygoogle || []).push({}); nand #(1,2) nand1(OUT,IN1,IN2); endmodule module Top; wire C ; reg A,B; nand_gate nand1(A,B,C); // Instantiation of lower block // Stimulate the input initial begin A=0; B=0; #5 B=1; #5 B=0; A=1; #5 B=1; #5 A=0; #5 B=0; end endmodule |