トップダウン設計（― せっけい）とボトムアップ設計とは、設計戦略である。トップダウンとボトムアップは、情報や知識の順序付け戦略であり、様々な分野で使われる用語である。この記事では、主にソフトウェア工学での用法について解説する。トップダウン設計は、段階的に詳細にしていく設計技法である。最初にシステム全体を定式化し、その時点では個々の詳細には立ち入らない。その後、システムの個々の部分の設計を段階的に詳細化していく。最終段階では、実装に移せるまで詳細化する。内部構造に立ち入らずに設計を行っている段階では、各部分をブラックボックスとして扱う。ボトムアップ設計では、最初にシステムを構成する個々の部品を細部まで設計する。そして部品群を組み合わせてより大きな部分を作っていき、最終的にシステム全体が構成される。ソフトウェア開発工程では、トップダウン設計とボトムアップ設計は重要な意味をもつ。トップダウン設計では、計画とシステムについての理解の完全性が重要となる。システムのある程度の部分の設計が十分な詳細さのレベルになるまでコーディングを開始することはできない。したがって、設計の大部分が完了するまで主要な機能のテストはできない。ボトムアップ設計では、モジュール単位の設計が完了した時点でコーディングとそのテストが開始できる。しかし、ボトムアップではモジュール間の関連が明確化されていないと後から設計変更が発生してしまう危険性があり、実際問題としてモジュール間の関連を最初から全て完璧に見通すことは困難である。ボトムアップ設計の利点の一つとして、コードの再利用性の高さが挙げられる。トップダウン設計は、1970年代にIBMの研究者ハーラン・ミルズとニクラウス・ヴィルトが提案した。ミルズは構造化プログラミングを実用化し、1969年にニューヨーク・タイムズ紙の資料検索の自動化プロジェクトで実践して成果を上げた。このことから、トップダウン設計がIBMや他のコンピュータ企業で広く採用されるようになった。ヴィルトはPascal言語の開発者であり、"Program Development by Stepwise Refinement" という論文が業界に影響を与えた。トップダウン設計は、1980年代にオブジェクト指向プログラミングが台頭してくるまで最も支持された手法であった。最近では、トップダウン設計とボトムアップ設計を組み合わせて設計する手法が一般的である。システムを完全に理解することは手法によらず重要であり、理論上はトップダウン設計が必要となる。しかし、多くのソフトウェアプロジェクトは、ある程度の既存のコードを流用する。既存のモジュールを流用すると、必然的にボトムアップ設計の考え方が持ち込まれる。設計手法によっては、部分的に機能するシステムをまず構築（設計とコーディング）し、そのシステムに要求仕様を満たすような機能を追加していくこともある。トップダウン・プログラミングは、従来的な手続き型言語で主流とされるプログラミング手法である。まず複雑な部品の設計が行われ、それをもっと細かい単純な部品に分割し詳細化していく。最終的に各部品がコーディングできるほど詳細化された時点で、プログラムを書き始める。これは、C++やJavaのようなオブジェクト指向言語で主流とされるボトムアップ・プログラミングの対極にある。トップダウン・プログラミングでは、まずメインの手続きを書く。その中には必要とされる関数名が登場する。その後、登場した各関数の実体を書いていく。これを、全関数を書き上げるまで繰り返す。各関数（サブルーチン）の機能は可能な限り小さくされるので、そのコーディングも単純でコード自体も小さくなる。ボトムアップ・プログラミングでは、一部の機能を選び、それを実装したコードをまず作成する。そのような単機能のコード群を書いた後で、それらを組み合わせて全体を構成していく。トップダウン・プログラミングの利点:トップダウン・プログラミングの欠点:構文解析は、（ファイルやキーボードからの）一連の入力を処理して、その文法的構造を決定することである。構文解析は自然言語の解析にも使われるし、コンパイラなどでコンピュータ言語の解析にも使われる。ボトムアップ構文解析は、最も下位の単位から解析していって上位の構造へと進んでいく戦略である。LR法などがある。一方、トップダウン構文解析は構文木の仮説を立てて、実際の構造がその仮説に合っているかどうかを調べていく。再帰下降構文解析などがある。

出典:wikipedia