クラスライブラリを設計するときのトップダウンアプローチとボトムアップアプローチ
私は、コード付きの楽譜を作成する目的で、西洋の平均律音楽理論の概念を表すクラスライブラリを設計しています（このためのライブラリとプログラムは他にもあると思いますが、自分で設計したいと思います）。私が抱えている問題は、最も基本的な概念（PitchClass）から始めて、上向きに構築し始めると、設計が非常に複雑になり、非常にすばやく制御不能になってしまうということです。私はそれを解体してやり直すことになります。
新しいアプローチを考えています。最後に、ライブラリをどのように使用するかを示すプログラム（コンパイルされません）を作成することから始めます。たとえば、設計プロセスの一部として、最初にライブラリに付属するサンプルプログラムを記述します。そうすることで、低レベルの設計決定に役立ち、設計の複雑さに負けないようにできることを願っています。
このアプローチはテスト駆動設計に似ていますが、サンプルプログラムが単一のクラスまたは関数に分離されておらず、代わりに多くの高レベルクラスのインターフェイスを示している点が異なります。
質問
ここで説明するトップダウン設計方法論は有効なアプローチですか？名前はありますか？私は一人で働いていますが、チームはこのようなアプローチを使用しますか？
これ は、特にWeb UIの設計とブラウザの違いの処理に関するものであるため、質問には答えません。
これ は、バックエンドとフロントエンドの仕様に関するものであるため、関係ありません。
これ は、特にMVCスタックへのアプローチに関するものであるため、重複していません。
Acceptance Test-Driven Development について説明しています。
ATDDの背後にある基本的な原則は、各ソフトウェア要件に受け入れテストが伴うことであり、受け入れテストは、実行されると、要件が満たされていることの証明を提供します。
受け入れテストは、要件の分析時とコーディングの前に作成されます。要件の要求者（製品の所有者、ビジネスアナリスト、顧客の代表者など）、開発者、およびテスターが共同で開発できます。開発者は、受け入れテストを使用してシステムを実装します。テストに失敗すると、要件が満たされていないという素早いフィードバックが得られます。
テストは、ビジネスドメイン用語で指定されます。用語は、顧客、開発者、テスターの間で共有されるユビキタス言語を形成します。
テストと要件は相互に関連しています。テストに欠けている要件は、適切に実装されていない可能性があります。要件を参照していないテストは、不要なテストです。実装の開始後に開発される受け入れテストは、新しい要件を表しています。
私は個人的にATDDの大ファンです。受け入れテストを伴わない要件は、まったく要件ではありません。彼らは願いです。
ここで説明するトップダウン設計方法論は有効なアプローチですか？名前はありますか？
はい、それはトップダウン設計と呼ばれ、まともな Wikipediaの記事 があります。特に、ライブラリに何をしたいか、どのように使用するかに基づいてライブラリをどのように編成したいかを理解する非公式なバリアントについて説明しています。
チームはこのようなアプローチを使用しますか？
はい。ただし、チームが大きくなるほど、全員が同じ目標に向かって作業を続けるために必要な形式が増えます。昔は、プログラマーが採用される前に、トップダウンの設計が紙で行われていました。