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

data structure would need to be analyzed and changed accordingly. Also, top-down
approaches rarely are used to solve very large, complicated programs.
Another drawback to the top-down approach is that programmers usually have to
approach a program as a series of single functions. As a result, programmers are not
likely to incorporate evolutionary changes in the data structures into the big picture of
the overall system. Thus, the top-down approach provides few ways to reuse existing
pieces of software.
In contrast, bottom-up design has the ability to be reused. Moreover, if the speci-
fications for the program change, this impact may not be as great as it would be if a
top-down approach were taken instead. 11

4.3.3 Data Flow or Structured Design

Data flow design sometimes is referred to as the structured design approach. Struc-
tured design is the companion method to structured analysis; that is, structured
analysis is functional and flat, whereas structured design is modular and hierarchal
(Laplante, 2005). By using the structured design approach, emphasis is placed on
the processing performed on the data, where the data are represented as a continuous
flow of information that is transformed from node to node in the input-output stream
(Khoo, 2009).
Structured design is characterized by the development of a structured hierarchy
of modules using structure charts (SCs). 12 SCs can be used to model a group of
functions defined in the specifications into modules. The SC also is used to model the
hierarchical organization of the modules and the data interface between the modules.
The building blocks of a SC are the module, the call, the shared data area, and the
couple. The module is an independently callable unit of code. The call is an activation
of a module, and the shared data represents data accessed from several modules. The
couple represents an item of data or control information passed between modules. 13
It should be noted that several significant issues are encountered when using
structured analysis and structured design in modeling a real-time system. One problem
with this approach is that concurrency is not depicted easily with structured design
(Laplante, 2005). Also, control flows are not translated easily into code as well
because they are hardware dependent.
The most troublesome part of structured design is that tracking changes can be
tricky. Even more disturbing is that any change in the program requirements generally
translates into significant amounts of code that will probably need to be rewritten. As
a result, this approach generally is unpractical to use if significant software changes
need to be made in the future. Moreover, it should be noted that none of these problem
usually originate in this magnitude when using object-oriented methods (Laplante,
2005).

11 http://www.bookrags.com/research/bottom-up-design-wcs/.
12 http://www.cs.wvu.edu/

∼ ammar/chapter-4.pdf.

13 http://www.cs.wvu.edu/

∼ ammar/chapter-4.pdf.