トップダウン手法とボトムアップ手法（トップダウンしゅほうとボトムアップしゅほう）は、設計などにおける情報や知識の順序付けの手法として対比されるものであり、この記事では、ソフトウェア工学を主として、様々な分野におけるトップダウン手法とボトムアップ手法の対比についてみてゆく。
設計 設計におけるトップダウン手法とボトムアップ手法は、トップダウン設計とボトムアップ設計である。
トップダウン設計は、システムの全体から始めて、段階的に詳細にしていく設計技法である。最初にシステム全体を定式化し、その時点では個々の詳細には立ち入らない。その後、システムの個々の部分の設計を段階的に詳細化していく。最終段階では、実装に移せるまで詳細化する。内部構造に立ち入らずに設計を行っている段階では、各部分をブラックボックスとして扱う。
ボトムアップ設計では、最初にシステムを構成する個々の部品を細部まで設計する。そして部品群を組み合わせてより大きな部分を作っていき、最終的にシステム全体が構成される。
「伽藍とバザール」の著者エリック・レイモンドの編纂するジャーゴンファイルでは、「トップダウン設計」（top-down design）のハッカー的反対(語)（hackish opposite）は「ボトムアップ実装」（bottom-up implementation）だとある。http://www.catb.org/~esr/jargon/html/B/bottom-up-implementation.htmlそれに倣うならば、この節は「設計と実装」の節とし、対比は「トップダウン設計とボトムアップ実装」とすべきかもしれない。
ソフトウェア開発 この節では、ソフトウェア開発工程における、トップダウン手法とボトムアップ手法についてみてゆく。
トップダウン手法では、計画とシステムについての理解の完全性が重要となる。システムのある程度の部分の設計が十分な詳細さのレベルになるまでコーディングを開始することはできない。したがって、設計の大部分が完了するまで主要な機能のテストはできない。ボトムアップ手法では、モジュール単位の設計が完了した時点でコーディングとそのテストが開始できる。しかし、ボトムアップではモジュール間の関連が明確化されていないと後から設計変更が発生してしまう危険性があり、実際問題としてモジュール間の関連を最初から全て完璧に見通すことは困難である。ボトムアップ手法の利点の一つとして、コードの再利用性の高さが挙げられる。
しかし後にミルズが提案しているソフトウェアクリーンルーム手法では、必要ならば上流の設計まで立ち戻る反復型開発をとることとしている（ソフトウェアクリーンルームの記事を参照）。
同じく1970年代に、研究者ニクラウス・ヴィルトもトップダウン手法を提案した。ヴィルトはPascal言語の開発者であり、Program Development by Stepwise Refinement という論文が業界に影響を与えた。しかし、Program Development by Stepwise Refinement でも、必要とあらばトップまでも立ち戻ってやり直さなければならないIn particular, they must be taught to revoke earlier decisions, and to back up, if necessary even to the top.、と明確に反復型開発の特徴が述べられており、トップダウン手法ではない。
最近では、トップダウン手法とボトムアップ手法を組み合わせて設計する手法が一般的である。システムを完全に理解することは手法によらず重要であり、上はトップダウン設計が必要となる。しかし、多くのソフトウェアプロジェクトは、ある程度の既存のコードを流用する。既存のモジュールを流用すると、必然的にボトムアップ設計の考え方が持ち込まれる。設計手法によっては、部分的に機能するシステムをまず構築（設計とコーディング）し、そのシステムに要求仕様を満たすような機能を追加していくこともある。
プログラミング トップダウン・プログラミングは、従来的なとされるプログラミング手法である。まず複雑な部品の設計が行われ、それをもっと細かい単純な部品に分割し詳細化していく。最終的に各部品がコーディングできるほど詳細化された時点で、プログラムを書き始める。これは、とされるボトムアップ・プログラミングの対極にある。
トップダウン・プログラミングでは、まずメインの手続きを書く。その中には必要とされる関数名が登場する。その後、登場した各関数の実体を書いていく。これを、全関数を書き上げるまで繰り返す。各関数（サブルーチン）の機能は可能な限り小さくされるので、そのコーディングも単純でコード自体も小さくなる。
ボトムアップ・プログラミングでは、一部の機能を選び、それを実装したコードをまず作成する。そのような単機能のコード群を書いた後で、それらを組み合わせて全体を構成していく。
トップダウン・プログラミングの利点: チームは常に目標をもって作業する。 チーム全員が互いの作業内容を知っている。 プログラミングが開始された時点で、不明な点は何もない。 コードは目的をもって整然と書かれるので、理解しやすい。
トップダウン・プログラミングの欠点: ほぼ全体がコーディングされるまで実行してみることができないので、テストが後回しになる。一方、ボトムアップ・プログラミングでは単体テストが可能である。トップダウン・プログラミングでは、プロジェクトの最終段階で集中してテストを行うことになるので、最後になって問題が多発することが多い。ただし、トップダウンであっても、スタブを多用したテストハーネスを作れば、早期の単体テストは可能であるが、それにはコストがかかる。 コーディングは、それ以前の設計の品質に直接依存する。仕様の詳細さが不十分だとコーディングできない場合がある。
構文解析
構文解析におけるトップダウン手法とボトムアップ手法は、トップダウン構文解析とボトムアップ構文解析である。
句構造文法（生成文法）以外にも形式言語の文法の捉え方にはいくつかあるが、ここではそれらに議論を限定し、そのうちでも特にBNFで定義されている文脈自由文法のことを考える。BNFにおいて各ルールの左側の非終端記号を以下では「左辺の非終端記号」、右側の記号列を「右辺の記号列」と呼ぶ。
トップレベルの左辺の非終端記号（プログラミング言語の場合は〈プログラム〉、一般の言語では〈文〉などといった名前の非終端記号であることが多い）から右辺の記号列への展開の操作を繰り返し、最終的に入力と一致する終端記号の列が得られるならば解析成功とするのがトップダウン構文解析であり、入力の終端記号の列から始めて右辺の記号列から左辺の非終端記号への還元の操作を繰り返し、最終的にトップレベルの左辺の非終端記号が得られるならば解析成功とするのがボトムアップ構文解析である。
脚注
外部リンク Program Development by Stepwise Refinement - Communications of the ACM, Vol. 14, No. 4, April (1971)