SOFTWARE DESIGN METHODS AND REPRESENTATIONS - Software Design for Six-Sigma: A Roadmap for Excellence - page 82

ways to create system diagrams. Some main types of UML diagrams include use-case
diagrams, class diagrams, and implementation diagrams. 9

4.3.2 Level-Oriented Design

There are two general approaches to level-oriented design, the top-down approach and
the bottom-up approach. The top-down approach starts at a top level and breaks up the
program into smaller functions. The smaller functions are more easy to analyze, easier
to design, and easier to code. However, there has to be a complete understanding of the
problem or system at hand when designing a system using the top-down approach.
The top-down process also is dependent on decisions made in the early stages to
determine structure (Khoo, 2009). Bottom-up design is an approach where a program
is written in a series of layers. Each component is viewed as a tool to solve the
problem. Bottom-up design is different from top-down design because the one need
not know the complete problem at the outset of programming. In bottom-up design,
it is important to recognize that a certain tool can solve a portion of the problem. 10
Well-written top-down approaches have been described by Nimmer as follows:

In practice, a programmer usually will start with a general description of the function
that the program is to perform. Then, a specific outline of the approach to this problem is
developed, usually by studying the needs of the end user. Next, the programmer begins
to develop the outlines of the program itself, and the data structures and algorithms to be
used. At this stage, flowcharts, pseudo-code, and other symbolic representations often
are used to help the programmer organize the program's structure. The programmer
will then break down the problem into modules or subroutines, each of which addresses
a particular element of the overall programming problem, and which itself may be
broken down into further modules and subroutines. Finally, the programmer writes
specific source code to perform the function of each module or subroutine, as well as to
coordinate the interaction between modules or subroutines (Nimmer & Nimmer, 1991).

Indeed, the top-down approach is a very modular approach to software design,
where the problem is broken down into smaller, more manageable tasks. Although
having a modular design has its advantages, there are drawbacks as well. For example,
this approach focuses on very specific tasks that have to be done but putting little
emphasis on data structures. In other words, data structures usually are only thought
of after procedures have been generally defined. Moreover, any data used by several
procedures usually are defined in one place and can be accessed by any module or
subroutine. This may create problems if the program needs to be updated or revised
because it “leads to the stack of dominoes effect familiar to anyone working in
program maintenance whereby changes to one part of a software system often cause
a problem in an apparently dissociated program area” (Barkan, 1993, p. 315). In
other words, every time software is updated, all the procedures that rely on the old

9 http://www.bookrags.com/research/uml-unified-modeling-language-wcs/.
10 http://www.bookrags.com/research/bottom-up-design-wcs/.