クラスの抽出なんですが。

ドメイン分析についてまとめてみたのですが、そもそも名詞抽出法、動詞抽出法
が気に入りません。ものすごくアバウトじゃないですか。

クラス抽出は、慣れるとこのどちらの方法も使わないでできるようになる、という

人もいるのでしょうが、それは小さいシステムの場合でしょう。大きなシステムな

場合、もっと確実なクラス抽出方法が欲しいところです。

何かよい方法はないものでしょうか・・・。

ドメインモデル

オブジェクト指向設計では問題領域と解決領域という言葉が
あり、問題領域についてモデリングされたモデルのことを
ドメインモデルというらしいです。

ドメインモデルというのは現実世界をそのままモデリングする
ことなので、再利用が可能なモデルなわけです。
（現実世界が激変することは無い、という考えに基づいている）

現実世界の中で、開発するシステムに関係あるところだけを
モデリングしましょう、というわけですね。

ドメイン分析をする時の作業順を自分なりにまとめてみます。

１ ドメイン分析のインプットである文章を書く。
　　1.抽象度の高い問題記述
　　2.抽象度の低い要求（システムで実現したいこと）
　　3.問題空間の専門知識（業務知識）
　どういう文章でも良いわけではなく、能動態で書くのがポイント。
　「システムは、〜〜を〜〜する。」
　というように、主語が〜する、〜できる、〜を許可する、という文体で書く。

２ これらの文章の名詞、名詞句に丸をつける。(クラス候補)
３ あいまいなクラス候補、重複、名詞句だけどアクションを示すものは除く。
４ クラス間で汎化の関係にあるものを探し、クラス図にする。
５ １の文章の動詞、動詞句に二重丸をつける。（関連候補）
６ ５からクラス間で集約の関係にあるものを探しクラス図にする。
７ ５からクラス間を関係付ける、関連クラスを作り（あるいは探し）、クラス図にする。

以上を１つのクラス図としてまとめる。
注意しなければいけないこと。
１ドメインモデルは、静的なモデルを目指すので、時系列に関係なく成立する
　モデルを書くことを忘れないようにしないといけない。
２クラス図に、属性、操作は書かない。
３多重度は書かない。
４わかりづらいクラス名はつけない。
５コンポジションか、集約か考える段階ではないので、コンポジションは集約にする。

要は、あまり細かいところを決めすぎるな、ということですね。
再構築の場合は、RDBのレイアウトも重要な情報源になるそうです。
その場合、RDBの項目はどのクラスの属性となるかを考えて、それらをまとめて
ヘルパークラスとしてあげればOK、だそうで。

ざっと書いてみたのですが、どう考えても、最初のインプットになる文章を
書くのが一番難しいような気がします。こればっかりはしょうがないんですかね・・・。
どうにか、この文章を書くためのテンプレートを作れないものでしょうか。