読書会(UMLモデリングの本質)第5回議事録

「 UML モデリングの本質」を読む会第５回(最終回)議事録
2004年10月16日
　出席者:高橋(徹)　高橋(智)　西野　吉村　松林　横山　村山　村上　奥　吉本　
　石黒　鈴木　岩永　坂本　根本(記)

P205～モデリングの実践より
P209の図7-1
   ピーターコードのビジネスパターン図　
   設計の中間過程が書いてないので読んでいて理解できない。
   クラス図が成長していく過程が重要。
   カラーUMLという表記があって目に優しいUMLもある。
   IDEのソースコード色づけ標準が欲しい　
   C#の様にJavaもthreadsafeかどうか全てjavadocに書いていて欲しい。
7.1.3　他人の書いたモデルを読む
　オブジェクト図を書くのが有効　Jude竹　はオブジェクト図が書ける
　inner class はどうやってテストするのか不明? (宿題)
　UMLの抽象/具象クラスの定義はJavaのクラスと同じ考えでいいのか→違う。
　カテゴリークラスを抽象クラスの代わりに使用するという話は
　enumのようなものと考えていいようだ。
　言葉でドキュメント記述すると多重度が見えない事が多いのでUMLが役立つ。
　UMLは多重度を説明するのに有用、
　n:m の多重度はObserverパターンに存在するので、必ずしも禁じ手ではない。
　ダブルディスパッチはn:mパターンの使い方のケースである。
　結城さんの本のVisitorパターン参照のこと。
　　　※ パターンハッチング本も参照のこと。
　図7-6 トリップとは・・・　ここでは、ひとつひとつの移動を指す。
　ひとつの有効期間に便が複数関連づけてあるか、この意味が不明。
7.2　定石にとらわれず無駄を取る
7.2.2 制約は妥当か
P218  (2)関連クラスを関連に戻す
　　3行目　「もの」に該当する「トリップ」と「引き当て」は、
　　「こと」同士の関連を表す・・・
　ここで「もの」と「こと」が逆に書いてある、誤記だろう。

　図7-12 図7-6の有効期間が途中から有効期限になっている、理由不明。
　　シートクラスの多重度が0..1だが、
　　これはスーパーシートのないフライトを想定しているのかもしれない。
　　オープンクラスから路線クラスへのみナビケートが付いているか、これでいいのか？
　　多分、強調表示したいのでナビゲートを付けたのだろう。
　　旅行プランと、トリップの間は強い集約だが、いまひとつ意味が分からない。
　
7.3 曖昧さや、矛盾を概念レベルで撲滅する
　図7-13 OCLの記述ミスはどう対応するのか?　syntax checkerはあるのか不明。
　OptimalJはOCLでなくAction Semanticsを使っている。
　 OCLは見づらい、なんとかならないのか。
7.3.2　ユースケースに基づく見直し
　　　図7-16 シートクラスは、行きと帰りの2つ必要なはず。
　　　図7-17 全てのmethodに **A**() (makeAReservation())と
　　　***s() (getAvailableSeats())
　　　と表記を分けて単複区別しているが、これは児玉さんの書き方だろう。
7.3.3 パッケージでくくる
　図7-19 トリップクラスから商品interfaceを参照しているが、他の路線クラスなどは、
　facadeパターンが適応されているので、変更されても、
　影響を受けないようになっているのか不明。
　パッケージが最後に出てきたが、本当にこのタイミングでいいのか？
　トップダウンなら、パッケージが先に作られるべきだと思う。
以上

[ 戻る ]