「ユースケース入門」の手法によれば、
現実模倣によるモデルは分析段階のドメインモデルと呼ばれる。
これは属性や操作のないクラス図として書かれる。

ユースケースとドメインモデルによって、そのソフトウェアが
「どう利用するか」と「どのような要素が存在するか」が分析される。
これらは問題領域に属する。

そして、この二つ（など）から「どう動作するか」を表したロバストネス図が書かれる。
クラスの役割、クラス間の関係が抽象度を保ったまま表現される。
ロバストネス図は問題領域から解決領域を導くための図である。

ロバストネス図（など）からクラス図が書かれる。
クラス図には属性や操作が書かれる。
属性や操作は他の図からそのまま移されるものが多いが、
パターン適用などのコーディング上の必要から新たに追加されるものもある。
クラス図は解決領域に属する。
----
駆け足かつ受け売りで書いたけど、
現実模倣はあくまで問題（=作るソフトウェアがどういうものか）を把握するために行なうのであって、
それをそのまま設計に使えることは少ないと思う。
オブジェクト指向プログラムがある程度抽象度の高い書き方ができるといっても、
現実にはプログラムとしての制約、入出力機器の制約、
接続するDBの制約などなどが存在するから。

あ、ﾈﾀ心者スレだったのか。スレ違いすまん。