みつじ＠ウェッブ制作です。
児玉さん、
> そのとおりです。Stateパターンは，動的分類の実装方法の一つです。
> 他にも実装方法はあって，アナパタの後ろにいくつか書いてあったよう
> に記憶しています。
アナパタも復習してみました。14.2に汎化の実装方法が5つ書いてあって、
動的分類の実装にはそのうちの3つが使えるようですね。
・フラグによる実装
・隠しクラスへの委譲（Stateパターン）
・代替オブジェクトの生成
3つめのやつはちょっと難しくてよく分かりませんでしたが、
Javaだと、同じ(Java言語の)interfaceを実装したクラスの
インスタンスで参照自体を入れ替えるってことなんでしょうか。。。
２つを見てみて、
「フラグによる実装」と「隠しクラスへの委譲（Stateパターン）」はどちらも
概念レベルのモデルで使ってしまいがちな、実装レベルのパターンなんだな
と改めて感じました。
やっぱり汎化で描いて制約で｛動的｝って書くのが、実装非依存を考えると
いいみたいですね。
> 現時点での状態を保持していればいいのか，状態の変化をすべて記録
> しておくのかによって，ちょっと異なります。前者なら動的分類にしま
> すが，後者なら通常のサブクラスのままです。動的分類ならオブジェク
> トは1つしかありませんから，他のクラスから多重度は1になりますが，
> 後者だと多重度は多になります。
なるほど。単純には行きませんね、勉強になります。
> そうですね。私も困っています。
> UMLではどうなっているのか調べる時間がないのですが，オブジェク
> トの表記に縦の関係をすべて記述してしまうのはどうでしょう。たとえ
> ば，「＜underline＞児玉：不良顧客：顧客＜/underline＞」のように
> です。
JUDEとかでインスタンス名に継承階層までさかのぼってクラス名を
出してくれると楽なんですけどね。
でもそこまで行くと「正しい」UMLではなくなってしまうでしょうね。
SadManさん、
> 背景が幾つかあって
> ひとつは、概念モデルと実装モデルは倍率は違うが構造は変わらないという事
> 仮にstateパターンを知らなくてもモデリングの素養があれば
> 必要ならば自ずとstateパターンがモデリングされるであろう事
>
> 等から、サービスの状態をstateパターンでモデリングする事に
> 非常に抵抗を感じるわけです
まったくおっしゃるとおりだと思います。
> 概念モデルの設計はいずれ実装にある種の強制力を与えるので
> 実際にこのお題において状態をクラスとして実装する人が居ればそれは悪い実装だと思うのです
>
> 外に出す必要に迫られたらその時にモデルを変えるべきものではないでしょうか
そうですね。「概念モデル」「設計モデル」「実装モデル」と段階的にモデルが詳細化されていく
過程で、使うのに適したパターンの種類や粒度も変わっていきますね。
（実装レベルで使う、GoF等の）デザインパターンなんかだと、実装に使うためには
使用する言語に特定の機能がないとダメな場合などもあるので、概念モデルでは
そこまで踏み込むべきではないと思います。
なんだか、実装の話ばかりになってすみません。。。
平澤さん、
> 状態遷移はクラス図ではなく、ステートマシン図で表現するのが筋だと思います。
> （ステートマシン図ならば、状態の種類だけでなく、遷移の規則もきちんと表現できます。）
> 動的分類は表現方法としてトリッキーですし、
> Stateパターンはご指摘の通り実装を制約する危険があります。
今回はクラス図の検証にオブジェクト図を使うというアプローチを取っているわけですが、
実務で使う際には、必ずしもそれにこだわる必要はないということですね。
> とはいえ、UMLのクラス図を使ったモデリングでは、
> RDBでの正規化理論のような基準がないため、
> ある意味「何でもあり」です。
私はRDBの方からオブジェクト指向に来た人間なので、クラス図を描くときも
正規化理論を意識してしまいます。その辺が実装を意識しすぎと言われる
原因のひとつかもしれません。
もっと柔軟な発想ができるようになりたいものです。