平澤です。
>清野（せいの）です。
>
>１．
>もう一つの観点として『状態』をモデリングする必要があるか？
>=>不要。
> 「業務上のイベント」を表現するクラスとして記述すべき。
> 「状態」は「イベント」の記録データから随時生成できる（する）。
私はビジネスアプリケーションでも、必要に応じて状態遷移を表現するモデルを書きます。
（といっても「受注」のような、ごく一部のエンティティに対してだけですが。）
理由は、ビジネスルールを確認するためです。
たとえばamazonのようなサイトなら
・発送準備に入ったらキャンセルできないこと
・取引成立後でも条件によって返品を受け付けること
などのビジネスルールがあると思います。
ステートマシン図はこの類の仕様を確認するために便利な道具です。
反対に、ユースケース（一覧／記述）や事実を記録するエンティティ構造だと、
こうした情報をズバリと表現できません。
>２．
>今回の概念モデルに『状態』を必要とする範囲が記述されるべきか？
>=>お題のタイミングのシチュエーションでは不要。
> 「受付業務」のみのモデルをベースに検討範囲が狭すぎないか確認し、
> その上で追加する。
今回のお題の文章には、状態遷移を表現するための情報がほとんど書かれてないため、
モデリングコンテストとしては不要だと思います。
しかし実際にクリーニング店のシステム開発をする場合なら、
私は「受注」の状態遷移を書くと思います。
これによって、受注の単位と返却の単位が違っていたり、
キャンセルや引き取りに来なかった場合の仕様など、
見落としやすいビジネスルールを引き出せる可能性がありますので。
>３．
>概念クラス図で「他のデータからルールで生成できるデータ」を記述すべきか否か？
>=>不要。
> ユーザが意図的に入力する以外のデータは意味の冗長性を生み、可読性が下がる。
> 代わりに、別途「生成のルール」をまとめる。（モデル上のノートや別表等）
（これに関するコメントは1.と同じです。）
--
平澤 章 <akira.hirasawa@....jp>