清野（せいの）です。
第2回コンテストは、時間不足で参加できませんでした。
後出しの意見で失礼いたします。
議論されているのは、『状態』についてのモデリングの仕方についてでしょうか。
これに対して2点ほど質問です。
第一に、
他の観点として『状態』をモデリングする必要があるか？
第二に、
今回の概念モデルに『状態』を必要とする範囲が記述されるべきか？
ということを考える必要はないでしょうか？
まず、一つ目です。
概念モデルで扱われる『状態』とは何を指すのでしょうか。
組み込み系のモデルであれば、
エレベーターのカゴの『稼動状態』や、
ビデオの「録画中」、「再生中」など、
『状態』を保持する必要性があることは、なんとなく想像できます。
＃そういったモデルを書いたことがないので想像ですが。
今回のお題において『状態』が具体的にモデリングされる必要性が、
強く感じられません。
開発太さんがおっしゃっているように概念モデルでは
『クリーニング＜＜業務について知りたい＞＞んです。』
ということが主たる目的であると思います。
だとすれば、『知りたい』＝『管理する必要がある』のは
「受付」、「クリーニング完了」、「渡し済み」
といった『状態』ではなく
「受付」、「クリーニング(実施)」、「渡し」
という『業務上のイベント』ではないでしょうか？
なぜならこの『業務上のイベント』によりシステムのユーザが、
システムに対して何らかの入力動作をする必要があるからです。
その入力データの受け皿として、（概念）クラスが必要になると考えます。
＃クラス名はクリーニング店経営の純白四郎さんに聞くと
＃もっとよい用語がありそうです。
逆に、これら「業務上のイベント」のデータの記録状況から、
『状態』は知ることができると思います。
ここまで書いて派生的に次の疑問（3点目の質問）が出てきました。
根本的に、概念クラス図でここで書いた『状態』ような
「他のデータからルールで生成できるデータ」を記述すべきか否か？です。
この要否によって、冒頭の『状態をモデリングすべきか？』の回答は
いとも簡単にぶれてしまいそうです。
第二の
今回の概念モデルに『状態』を必要とする範囲が記述されるべきか？
についてです。
お題の中で開発太さんは
『対費用効果の高い部分をシステム化』
をパッケージに対する優位点としてあげています。
そして今回のお題では、次の内容が議論されています。
1)受付
2)タグ取り付け
3)チケット発行
いずれも「受付業務」での作業であり、これだけをシステム化するならば
『状態』そのものが不要であると思います。
お題においても、
4)クリーニングを行い
5)出来上がりを渡す
という部分については触れられていません。
この範囲が対象範囲に入ってこそ『状態』の必要性が出てくると思います。
実際には、システム化対象の候補の範囲をモデリングし、その上で
『対費用効果の高い部分』を検討することになると思いますので
4),5)も概念モデルに含まれることになるのだろうとは、想像します。
ですが、お題のタイミングのシチュエーションで、
＃『さて、開さんはどんな図を書いたのでしょうか。
＃純白さんに教えてもらった内容がうまく盛り込めているでしょうか？
＃わかりやすいようなモデルを作れたでしょうか？』
いきなり4),5)まで概念モデルを開発太さんが書き上げてるとすると脱帽です。
というのは、考えすぎ（揚げ足取り）でしょうか。
以下3点についてでした。
あわせて現時点での私の考えも記述します。
１．
もう一つの観点として『状態』をモデリングする必要があるか？
=>不要。
「業務上のイベント」を表現するクラスとして記述すべき。
「状態」は「イベント」の記録データから随時生成できる（する）。
２．
今回の概念モデルに『状態』を必要とする範囲が記述されるべきか？
=>お題のタイミングのシチュエーションでは不要。
「受付業務」のみのモデルをベースに検討範囲が狭すぎないか確認し、
その上で追加する。
３．
概念クラス図で「他のデータからルールで生成できるデータ」を記述すべきか否か？
=>不要。
ユーザが意図的に入力する以外のデータは意味の冗長性を生み、可読性が下がる。
代わりに、別途「生成のルール」をまとめる。（モデル上のノートや別表等）
−−
清野博之 hseino@....jp