To: モデリング道場のみなさま
庄司＠NEC情報システムズです。
モデリングコンテスト２で、最優秀モデルに選んでいただきました。
投票・評価していただいたみなさま、ありがとうございます。
私が作成したモデルは、他の方の作品と比較すると、シンプルな
作りとなっており、その辺りが評価されたのかと感じております。
（自分では、シンプルというよりも実用性重視だと思っています）
＊＊＊
それで、他の方の参考になるかどうかわかりませんが、作成する際に
考慮したポイントを、以下に何点か書きたいと思います。
■ クリーニング品目の取り扱い
クリーニングの品目には、シャツやコートなど色々あると思います。
これらの品目は、純白さんのクリーニング業務の中では別物と扱わ
れるかもしれませんが、システム上での振る舞いに相違は無いと
考え、全て同じクラスとしました。
■ クリーニングサービスの取り扱い
こちらも、クリーニング品目と同様、防虫加工や防水加工など、
色々とあるわけですが、やはりシステム上の振る舞いはどれも同じ
だと考え、同じクラスにしました。
■ クリーニング品目とクリーニングサービスの関連
最初、クリーニング品目とクリーニングサービスの関連に注目し、
品目によって可能なサービスと、そうでないものがある、という
制約を、うまくモデル上で表現できないかどうか考えました。
で、あれこれとクラスの構造を考えたのですが、実際の業務を考え
たときに、あるクリーニング品目に対して、可能なサービスを決定
するのは、システムを使う人がやればよいという結論に達しまして、
単にクリーニング品目とクリーニングサービスに関連線を引くだけ
というモデルになりました。
モデル上で制約が存在しないため、品目とサービスのありえない
組み合わせも当然設定できます。でも、こういうのは使う人が設定
しなければ良いだけですし（運用でカバー）、もし、設定できる
ようになったとき、その変更コストが高くつくのも望ましくない
と思いました。
■ 料金の改定
これは今回、自分で解決できなかった考慮点です。
今回のモデルには入れなかったのですが、本当は料金クラスの
属性に、"設定日" というのを追加しようとしていました。
これによって料金の変更を簡単にし、かつ履歴も管理できるように
するはずでした。でも、ちょっと調べたところ、UML のルールでは、
関連クラスのインスタンスは必ずひとつしか存在してはいけない
ようでした。どうしようか悩んだのですが、他のうまいやり方が
すぐに見つからなかったので、今回は泣く泣く外すことにしました。
こういう場合関連クラスとせず、他の方のモデルのように品目と
サービスの間に料金クラスをはさめば良かったのでしょうか？
== オマケ ==
（当時の）Jude では関連クラスを書くことができなかったため、
クラスの位置だけ書いて、別のペイントツールで点線を引いて
応募しました。(^^;
以上です。
----------------------------------------------
庄司 順和 <y-syouji@....jp>
NEC情報システムズ SI基盤事業部 オブジェクトテクノロジグループ
tel:044-812-8424 telnet:8-339-4563 mail:155-35