こんにちは，児玉＠(株)エクサです。
山本さん，
のんびりやっていたら，第２回のコンテストが始まってしまいまし
たね。
「[modeling-dojo:00230] Re: 苦しいです＞別なシナリオで＞ 強烈な揺さぶり＞ Re: コンテ
スト アフター ザ コンテスト」のお返事させていただきます。
> あっ！！「その仮定は適応出来’ない’のでは…」の脱字でした。
>すみません。
あ，やっぱり。
>今回のシナリオ２では，「配達依頼したもの」と「配達したもの」は同じ
>オブジェクトなんですが，形状についてクレームがついています。
> ただ，今回のシナリオ２の場合，「形状が変わった」という基準が
>私は微妙なように思えており，「形状が変わった」とするのは，
>「依頼者」の評価のため，「依頼者」と「配達品」には，「評価」などの
>クラスが必要ではないかと考えていました。
評価は操作（メソッド）じゃないかな。ひょっとしたら「依頼者」が
行う操作で，実装イメージとしては，適当なGUIをつけて，「OK」，「NG」
と入れるだけとかね。
その結果として，配達品の分類が変わるとか，「配達作業」が失敗に
終わったと分類されるとか，何らかの状態変化があると書きたいです。
この辺り，アナリシスパターンの８章「計画」の記述が参考になると思
います。これと「基準」を組み合わせたら，すごいビジネスモデルにな
るような予感がします。
> 頂いたアドバイスを元に，オブジェクト図とクラス図を修正してみました。
>○オブジェクト図
> | ムレーム無:予定配達作業-------ムレーム有:実績配達作業 |
（クレームですよね）
ここ。ここがアナパタの「計画」にかかわるところなんです。
>○クラス図
> +--------+*依頼品 +------------+ +--------+
> | 配達品 |------------| 宅配担当者 | | バイク |
> +--------+ 1+------------+ +--------+
> 1| 1|届品 1|作業者 0..1|占有
この占有はなぜ必要ですか。バイクのスケジューリングをやりたいの
だったら，時間情報が必要で，それを保持する「占有」クラスが必要。
そしてそれが，「予定」に関連すると思います。
> |1 | +---------------+ |
> +------+ --------------| 配 達 作 業 |-----------
> | 位置 | *+---------------+*
> +------+ △
「位置」だけじゃなく，「形状」も「配達品」に付ける手があります。
それと，評価の結果の分類も考えるといいでしょう。
> しかしこれは，本題ではないので，本来の業務システムのシナリオを
>考えさせて頂きます。
いや，配送の初期モデルとしてはいいと思います。もう，業務シス
テムはどうでもよくなってきました。
> 今回のオブジェクト図で，「アップルパイ:配達品」３つと「B宅:届先」２つと
>オブジェクトを複数個あげてしまいました。
> 私は，基本的にオブジェクトは１つしか書かないと思っていたのですが，
>これらのオブジェクトを１つに纏めて書いてしまうと，繋がりが良くわからなく
>なってしまう気がしています。
>それとも，クラス図に問題があるため，そうなってしまうのでしょうか。
これだと別のオブジェクトになっています。アップルパイ１，アッ
プルパイ２，アップルパイ３があります。
つながりがよく分からなくなるというのは，どこか間違えているか
らだと思います。１つのオブジェクトは１つにして，ちゃんとリンク
がたどれることを確認してみましょう。
それと，どこからどこへ何かを移動する場合の典型的なモデル構造
がありますよね。もう，パターンと言っていいくらいの。
ということで，もう少し考えを整理してみましょう。もうちょっと
考えればいいんじゃないかな。配送モデルとしてはですけど(^o^)。
その前に，第２回コンテストにtryしてみませんか。
----
児玉公信
(株)エクサ SPBOMソリューションオーナー
兼 技術部
kiminobu-kodama@....jp kodamak@....org
児玉流メール道 家元