To: 平澤さん、立見さん
庄司＠NEC情報システムズです。
コメントいただきまして、ありがとうございます。
>ただ非常に残念ながらNo.31のモデルには、1つだけ微妙な間違いがあります。
>それは「料金」を関連クラスにしてしまっていることです。
>
>「関連クラス」は、関連がないと存在できないため、
>品目に依存しない”防虫加工”の料金を設定できません！
防虫加工の料金は品目によらず一定というのは、確かに今回の
モデル上で表現していません。これは、考慮から漏れてしまった
のではなく、わざとモデルから外しています。
確かに、現在の事実を見ると、防虫加工は品目によらず一定の
価格になっているのですが、これは、たまたまそうなっている
だけだと捉えました。
もし今後、例外的に防虫加工の料金が異なる品目を取り扱いたい
と思ったとき、これに対応するためにはモデルを変更するか、
防虫加工のクラスを変更する必要が出てきます。
そのため、防虫加工のような料金一定のサービスを特別扱い
することはせず、他のサービスと同様の扱いとしています。
こうすると、メンテナンス方法が若干面倒にはなると思ったの
ですが、それはモデルの動的振る舞いでうまく対応すれば良いと
考え、静的構造図上では表現していません。
>お題の文章を読む限り、標準日数の話は書いてありませんので、
>「サービス料金」でOKだと思います。
>ただ、実際の現場では「標準日数」などを管理するべきかを確認する必要がありますね。
>その場合は「クリーニングサービス」といったエンティティ名にすべきと思います。
標準日数のような属性があれば、クリーニング業務を知らない
人でも引渡し日を案内できるようになりますし、便利な機能に
なりそうです。
こういった機能に対する拡張性を考えると、確かに私のモデルでは
クラス名を変更しないとうまく対応できそうにありません。
ありがたいご指摘です。
>（今回のお題には書いてありませんが）
>料金の改定（値上げ、値下げ）まで表現する場合は、
>[クリーニング品目]と[クリーニングサービス]の関連エンティティの名前を
>[クリーニングサービス]あたりにして、
>[クリーニングサービス] 1--* [料金]
>と表現すればいいと思います。
>
>[クリーニングサービス]と[料金]を1--*とせず、
>限定子に[期間]を設定して、1--1とした方がスマートかも知れませんが。
なるほど、関連クラスに関連するクラスを、さらに追加すれば
良いわけですね。確かにそれなら表現できそうです。
しかし、関連クラスというのは、なかなか扱いが難しいですね。。
以上です。
----------------------------------------------
庄司 順和 <y-syouji@....jp>
NEC情報システムズ SI基盤事業部 オブジェクトテクノロジグループ
tel:044-812-8424 telnet:8-339-4563 mail:155-35