ソフトウェアシステム（プロジェクト）のクラス（そしておそらくそれらの責任）を特定するのに役立つ方法（テクニック）を探しています。私は多くのソフトウェア設計の本があることを知っていますが、これがシステムのクラスであるべきであり、これらがその責任であることを知る方法を特に探しています。
ソフトウェアプロジェクトのクラスのリストを作成する方法のスキルを向上させたいです。仕様書と要件書を読んだ後、クラスのリストを知るのに役立つテクニックはありますか？
デザインパターンブックを探しているのではありません。私はむしろ、ソフトウェアプロジェクトのクラスを考え出すために採用できるテクニックを探しています。
私はあなたのすべての貢献、本の提案、記事へのポインタ、チュートリアルなどを歓迎します。
グーグルで検索しましたが、意味のあるものが見つかりませんでした。
助けてくれてありがとう。
添加：：
また重要なもう1つの領域は、クラス間のコラボレーションを決定する方法です。どのクラスが他のクラスを必要としているかを判断する方法。
通常、名詞は、動詞がメソッドであり、形容詞が注釈である要件からクラスに最適に転送されます。
.ie 車がエンジンを始動する
クラス: 車 メソッド: startEngine()
仕様と要件のドキュメントを読んだ後に、クラスのリストを知るのに役立つテクニックはありますか?
いいえ、それはひどくナイーブです。
すべてのソフトウェア ソリューションは、「問題領域」の要件を満たし、「派生」要件を満たすという 2 つの目的を持つクラスの組み合わせです。大まかに言えば、派生要件は、データベースへの保存など、やらなければならないすべての技術的なことの結果です。この 2 つが出会い/相互作用しなければならないということは、私たちがデザインパターンを持っている大きな理由です。
秘訣 (別名テクニック) は、ビジネス要件に焦点を当て、それらの要件をプロパティとメソッドとして表現するクラスをスカルプトすることです。コンピューター関連のものから離れてください。「個人データを保存する」必要がある場合は、問題ありません。しかし、どうやってそれを行うかについて心配する必要はありません。あなたの「ビジネスモデル」をビジネス用語やコンセプトで表現するデザイン。
開始するのに適した場所は、@FridayChlis が言うように、名詞 == クラス、アクション動詞 == メソッドです。そして、その形容詞 (しばしば) == プロパティを追加します。
これらのクラスがどのように相互作用するかのシナリオを設計することにより、設計を改良PersonしBankますWithdraws Money。このようにして、クラスがどのように相互作用するかを確認し、設計と要件の欠陥と欠点を発見します。すべてのビジネス要件が満たされるまで、必要に応じてこのプロセスを繰り返します。
UML ダイアグラムの研究。これは、ソフトウェア システム設計 (およびドキュメント!) 用の標準化された一連の図です。警告。利用可能な図のすべて、またはほとんどを使用しようとしないでください。