トップダウン設計とボトムアップ設計

トップダウン設計とボトムアップ設計（トップダウンせっけいとボトムアップせっけい）とは、設計戦略である。トップダウンとボトムアップは、情報や知識の順序付け戦略であり、様々な分野で使われる用語である。この記事では、主にソフトウェア工学での用法について解説する。

概要

トップダウン設計は、段階的に詳細にしていく設計技法である。最初にシステム全体を定式化し、その時点では個々の詳細には立ち入らない。その後、システムの個々の部分の設計を段階的に詳細化していく。最終段階では、実装に移せるまで詳細化する。内部構造に立ち入らずに設計を行っている段階では、各部分をブラックボックスとして扱う。

ボトムアップ設計では、最初にシステムを構成する個々の部品を細部まで設計する。そして部品群を組み合わせてより大きな部分を作っていき、最終的にシステム全体が構成される。

ソフトウェア工学

ソフトウェア開発

ソフトウェア開発工程では、トップダウン設計とボトムアップ設計は重要な意味をもつ。

トップダウン設計では、計画とシステムについての理解の完全性が重要となる。システムのある程度の部分の設計が十分な詳細さのレベルになるまでコーディングを開始することはできない。したがって、設計の大部分が完了するまで主要な機能のテストはできない。ボトムアップ設計では、モジュール単位の設計が完了した時点でコーディングとそのテストが開始できる。しかし、ボトムアップではモジュール間の関連が明確化されていないと後から設計変更が発生してしまう危険性があり、実際問題としてモジュール間の関連を最初から全て完璧に見通すことは困難である。ボトムアップ設計の利点の一つとして、コードの再利用性の高さが挙げられる。

トップダウン設計は、1970年代にIBMの研究者ハーラン・ミルズとニクラウス・ヴィルトが提案した。ミルズは構造化プログラミングを実用化し、1969年にニューヨーク・タイムズ紙の資料検索の自動化プロジェクトで実践して成果を上げた。このことから、トップダウン設計がIBMや他のコンピュータ企業で広く採用されるようになった。ヴィルトはPascal言語の開発者であり、Program Development by Stepwise Refinement という論文が業界に影響を与えた。トップダウン設計は、1980年代にオブジェクト指向プログラミングが台頭してくるまで最も支持された手法であった。

最近では、トップダウン設計とボトムアップ設計を組み合わせて設計する手法が一般的である。システムを完全に理解することは手法によらず重要であり、理論上はトップダウン設計が必要となる。しかし、多くのソフトウェアプロジェクトは、ある程度の既存のコードを流用する。既存のモジュールを流用すると、必然的にボトムアップ設計の考え方が持ち込まれる。設計手法によっては、部分的に機能するシステムをまず構築（設計とコーディング）し、そのシステムに要求仕様を満たすような機能を追加していくこともある。

プログラミング

トップダウン・プログラミングは、従来的な手続き型言語で主流とされるプログラミング手法である。まず複雑な部品の設計が行われ、それをもっと細かい単純な部品に分割し詳細化していく。最終的に各部品がコーディングできるほど詳細化された時点で、プログラムを書き始める。これは、C++やJavaのようなオブジェクト指向言語で主流とされるボトムアップ・プログラミングの対極にある。

トップダウン・プログラミングでは、まずメインの手続きを書く。その中には必要とされる関数名が登場する。その後、登場した各関数の実体を書いていく。これを、全関数を書き上げるまで繰り返す。各関数（サブルーチン）の機能は可能な限り小さくされるので、そのコーディングも単純でコード自体も小さくなる。

ボトムアップ・プログラミングでは、一部の機能を選び、それを実装したコードをまず作成する。そのような単機能のコード群を書いた後で、それらを組み合わせて全体を構成していく。

トップダウン・プログラミングの利点:

• チームは常に目標をもって作業する。^[要出典]
• チーム全員が互いの作業内容を知っている。^[要出典]
• プログラミングが開始された時点で、不明な点は何もない。
• コードは目的をもって整然と書かれるので、理解しやすい。

トップダウン・プログラミングの欠点:

• ほぼ全体がコーディングされるまで実行してみることができないので、テストが後回しになる。一方、ボトムアップ・プログラミングでは単体テストが可能である。トップダウン・プログラミングでは、プロジェクトの最終段階で集中してテストを行うことになるので、最後になって問題が多発することが多い。ただし、トップダウンであっても、スタブを多用したテストハーネスを作れば、早期の単体テストは可能であるが、それにはコストがかかる。
• コーディングは、それ以前の設計の品質に直接依存する。仕様の詳細さが不十分だとコーディングできない場合がある。

構文解析

→詳細は「トップダウン構文解析」および「ボトムアップ構文解析」を参照

構文解析におけるトップダウンとボトムアップという用語、ないしはトップダウン構文解析とボトムアップ構文解析は、設計戦略でもなければ、情報や知識の順序付け戦略でもない。そもそもソフトウェア工学での用語や用法とは全く関係なく、また「組織における意見流通の用語が原義で、行政学や経営学、特に経営学での意思決定論で、日米企業比較の主要な焦点という非常に重要な事項」など（当記事のノートを参照）とも無関係な、単に普通の英語の表現である「トップダウン」と「ボトムアップ」からの用語・用法である。すなわちこの記事の冒頭の定義がまともなものとするならば、この節はこの記事に書かれるべきではない。

句構造文法（生成文法）以外にも形式言語の文法の捉え方にはいくつかあるが、ここではそれらに議論を限定し、そのうちでも特にBNFで定義されている文脈自由文法のことを考える。BNFにおいて各ルールの左側の非終端記号を以下では「左辺の非終端記号」、右側の記号列を「右辺の記号列」と呼ぶ。

トップレベルの左辺の非終端記号（プログラミング言語の場合は〈プログラム〉、一般の言語では〈文〉などといった名前の非終端記号であることが多い）から右辺の記号列への展開の操作を繰り返し、最終的に入力と一致する終端記号の列が得られるならば解析成功とするのがトップダウン構文解析であり、入力の終端記号の列から始めて右辺の記号列から左辺の非終端記号への還元の操作を繰り返し、最終的にトップレベルの左辺の非終端記号が得られるならば解析成功とするのがボトムアップ構文解析である。

脚注

関連項目

• トップダウン手法
• 上意下達

外部リンク

• Program Development by Stepwise Refinement - Communications of the ACM, Vol. 14, No. 4, April (1971)