SadManさん
平澤です。
私もSadManさんの意見に賛成です。
状態遷移はクラス図ではなく、ステートマシン図で表現するのが筋だと思います。
（ステートマシン図ならば、状態の種類だけでなく、遷移の規則もきちんと表現できます。）
動的分類は表現方法としてトリッキーですし、
Stateパターンはご指摘の通り実装を制約する危険があります。
とはいえ、UMLのクラス図を使ったモデリングでは、
RDBでの正規化理論のような基準がないため、
ある意味「何でもあり」です。
もっともファウラー氏（＆オデール氏）のアナリシスパターンは、
この「何でもあり」を持ち込んだところが斬新で面白かったんですが、
実務で使うのは要注意だと思います。
（以下、引用のみ）
>SadManです。興味があるので横から首を突っ込んでみます。
>
>以前にポストした内容とかぶりますが
>今回のお題で状態をstateパターンで表現する事に抵抗がある。という話です。
>
>stateパターン自体の論理性は確かに正しいと思うのですが
>感覚的には状態が独立した意味を持っていたり
>横断的な状態を示していたり
>状態自体が複雑であったり状態の履歴を管理したり
>という要件がなければ単にフラグ的な状態を示すものに
>stateパターンを「実装する」のは良くないのじゃないかという考えです。
>
>背景が幾つかあって
>ひとつは、概念モデルと実装モデルは倍率は違うが構造は変わらないという事
>仮にstateパターンを知らなくてもモデリングの素養があれば
>必要ならば自ずとstateパターンがモデリングされるであろう事
>
>等から、サービスの状態をstateパターンでモデリングする事に
>非常に抵抗を感じるわけです
>
>概念モデルの設計はいずれ実装にある種の強制力を与えるので
>実際にこのお題において状態をクラスとして実装する人が居ればそれは悪い実装だと思うのです
>
>外に出す必要に迫られたらその時にモデルを変えるべきものではないでしょうか
>
>SadMan
>
>
--
平澤 章 <akira.hirasawa@....jp>