こんにちは，児玉＠(株)エクサです。
小林さん，
連休明け早々，出張の新幹線の中で書いています。
「[oosquare-ml:04276] Re: 「 ATM の整備員は故障中の ATM を修理する」をどうあらわす？」のお返事
させていただきます。
>> 小林さんはATMの状態を｛complete｝にしていますが，果たしてそう
>> ですか。
>
>たしかに、「使用中・停止中・故障中」または「正常・故障中」で｛complete｝としてしまうと、おか
しいように思います。
>「サービス時間外」とか「本部がトラブル対応中」とか、他にもいろいろなケースがありそうです。
そうですよね。それにこの状態の遷移には一定の制約がありそう
ですし。
>なるほど。「取引」や「保守」といった行為も、オブジェクトとしてモデル化するとだいぶやりやすく
なりそうです。
はい，ビジネスシステムには事実の記録が必要なのです。
>ただ、お示しいただいた図で理解できない点があります。
>「時点」というのはどういう時点でしょうか？
>「取引や保守を行った時点を記録する」ということであれば、「ATM」ではなく「取引」「保守」に関連
が引かれているべきではないかと思いますが...
>何か勘違いをしていますでしょうか？
ATMは時間の流れに並行して《動的》に状態が変わる。ある時点
では「故障中」，また別の時点では「使用中」というようにです。
これはスケジューリングでよく見られる「資源（resource）」の
扱いと同じです。
では，時点別に異なるオブジェクトがあるのかということになり
ますが，概念モデルではそこまでは述べていません。そう実装して
もいいし，１つのオブジェクトが時点ごとに状態を持つように実装
してもかまいません。そこをあえて曖昧にしています。
ユースケースが厳密な状態の記録を必要とすれば，時点（あるい
は区間）ごとにATMの状態オブジェクトを残しておくことになるか
も知れません。
「取引」や「保守」に，なぜ「時点」がついていないかですが，
これは当たり前なので省略しています。「時点」はFowlerのいう
基本型（foundation type）なので，実装上は属性として扱うのが
普通です。関連線を引きたければ，「取引」，「保守」から「時点」
に引きます。文字絵だとめげるでしょ(^^)。
>> ATMの状態は省略，保守の種類も省略。ATMの状態によって可能な保守
>> のタイプが異なるのは制約で記述します。どなたかOCLでtryしてみてく
>> ださい。
>
>状態 = #故障中 implies 保守タイプ = #修理
>状態 not #故障中 implies 保守タイプ = #点検
>
>といった感じでしょうか。OCLについては初耳状態で、しかもまとまった解説を発見できませんできたの
で、まったく自信はありません。
解説としては，Eriksson & Penkerの「UMLによるビジネスモデ
リング」にあります。意外でしょ。あと，拙著でよければ「UMLモ
デリングの本質」に解説があります。
----
児玉公信＠(株)エクサ
エンタープライズソリューション事業部SPBOMソリューション部
兼 技術部
***************@********.**.** *******@***.***
児玉流メール道 家元