みつじ＠Web制作です。
清野さん、
>開発太さんがおっしゃっているように概念モデルでは
> 『クリーニング＜＜業務について知りたい＞＞んです。』
>ということが主たる目的であると思います。
>
>だとすれば、『知りたい』＝『管理する必要がある』のは
> 「受付」、「クリーニング完了」、「渡し済み」
>といった『状態』ではなく
> 「受付」、「クリーニング(実施)」、「渡し」
>という『業務上のイベント』ではないでしょうか？
>なぜならこの『業務上のイベント』によりシステムのユーザが、
>システムに対して何らかの入力動作をする必要があるからです。
>その入力データの受け皿として、（概念）クラスが必要になると考えます。
>＃クラス名はクリーニング店経営の純白四郎さんに聞くと
>＃もっとよい用語がありそうです。
>
>逆に、これら「業務上のイベント」のデータの記録状況から、
>『状態』は知ることができると思います。
もう一度、開発太さんのコメントを見てみましょう。
-------------------------------------------------------------------
「せっかく新規開発するんですから、できるだけ対費用効果の高い部分を
システム化しましょう。そのために、クリーニング屋の仕事の全体を
把握する必要があります。まずはどんなシステムにするのかは考えずに、
クリーニング業務について知りたいんです。
「クリーニングの仕事をざっと教えてもらえますか？」
-------------------------------------------------------------------
ここで重要なのは、
『まずはどんなシステムにするのかは考えずに、』
というところだと思います。
上記コメントから、今回のモデリングの目的は「クリーニング店」という
問題領域（ドメイン）の分析であることが分かります。
「クリーニング店業務向けシステム」の（要求）分析ではありません。
私は、清野さんの考え方は、ドメイン分析向きというよりは、
開発工程ではその次に位置する、要求分析向きであるような
印象を受けました。「システムに対して何らかの入力動作をする」などの
発言から読み取りました。
ちょっと一般的でないかも知れないので、間違っていたら誰か
指摘してほしいのですが、
ドメイン分析（概念モデル）の段階では静的構造を重視し、
要求分析（要求モデル）の段階でイベントを重視するのだったと思います。
ドメイン分析段階では属性のみを用いたクラス図を使って問題領域
の静的構造を分析し、要求分析段階でユースケース図でシステムに対する
機能要求を抽出し、個別のユースケース記述で業務上のイベントの流れを
分析するのだと思います。
清野さんのおっしゃるようなイベントは、クラス図ではなく
アクティビティ図で描くものなのではないでしょうか。
「イベントの記録状況から状態を知る」に似た事象としては、
預金口座へのお金の出し入れの記録から預金残高が分かる、
みたいなものが頭に浮かびました。ただ、状態と呼べるようなものでは
ないような気がします。
>ここまで書いて派生的に次の疑問（3点目の質問）が出てきました。
>根本的に、概念クラス図でここで書いた『状態』ような
>「他のデータからルールで生成できるデータ」を記述すべきか否か？です。
>この要否によって、冒頭の『状態をモデリングすべきか？』の回答は
>いとも簡単にぶれてしまいそうです。
設計モデルの段階であれば、派生データは操作（メソッド）の処理の
結果として表現できますが、概念モデルでは普通は属性しか使わないので、
モデラーにとって重要であれば「/」などで派生データであることを
明示すれば書いてもよいのではないでしょうか？
そういう次元の話しではないのでしょうか。。。
>第二の
>今回の概念モデルに『状態』を必要とする範囲が記述されるべきか？
>についてです。
>
モデラーが何に重きを置くかによって変わると思うので、
一般的な回答を出すのは難しいような気がします。