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

[ 戻る ]

「 UML モデリングの本質」を読む会第３回議事録
2004年 8月21日
出席者
　高橋(徹) 村上 上手 吉村 根本 村山 松本 金 中村 大仲 西野 山口
　吉本 岩永 戸田 大江 中原 高橋(智) 石黒 遠藤 根本(記)　　敬称略

  p93 第3章より
概念レベルから実装レベルへ
3.1 概念レベルのクラス図を実装レベルに変換する。
　プロジェクト管理におけるフェーズとは何?
　単なるウォーターフォールでいうフェーズのことか？
  (4)動的分類を実装で扱える形にする。
  この設計でいいのか、
  StatePatternをつかうべきか enum でいくべきか？
  テストの容易性ではPattern-wg的思考では、
  stateパターンで分割するべきところである。
  stateパターンのいいところは可変部と固定部を分けている。
  フラグを持つクラスはバグを呼び出す switch文 if文は避けたい。
  紛失、予約中、とかの新stateが追加可能なのが、stateパターンのメリット。
  isProcessingステートがp98の図からp117の図で増えているが、どういうことか?
  stateパターンの適応ミスの可能性はどう判断するのか？
  (5)多重分類の展開
  　要注意学生:始末書の提出() 要注意職員:弁償()  を
  　制裁()メソッドでオーバーライドできるのではないのか?
  　制裁()インターフェイスに昇格出来るかどうかは、まだ不明なので、
  　説明的に書いたのではないのか。
  　実装をイメージして設計するのか、それともデザインのみで考えるのか。
  　ケータイの世界では、有限オートマトンの状態遷移図をMDAといっているらしい。
3.1.2インスタンスの管理
 　OID使っているのか？　SNMPとかではMIB treeをOIDで管理しているので、
 　実際に使っている。
 　Javaでいう、リファレンスはC++でのポインターか？
 　Pascalならリファレンス。
 　ここでいうOIDは数字とかではなくて、参照用のなんらかの名前にすぎない。
 　C#BuilderとかもOID生成している、使ってはいる。
3.1.3 関連の設計
 　双方向参照はUnreachableになる可能性があり、好ましくない。
 　しかし、分散Objectなら、呼出すまで実体の存在が、
 　分からないというのは、よくある話である。
 　Null化の通知を参照元へ通知する必要がある。
   GCの実装を考えないとクラス設計できないのではないのか？
3.2 インターフェイスの設計
3.2.1 責務の割付とインターフェイスの設計
   P.110L4  システムが"重く"なる。メソッドがひとつ増えることを、
   重くなるといえるのか。
3.2.2 アーキテクチャーに対応づける
　 宿題:Application Fassadeの調査
   図3.11  誤植　　4: add(this) -->add(貸し出しルール)　
  "Domain Driven Design" の本が副読本に適切、海運業界の実装例が載っている。
   P117 図3.13 Bookクラスの "/copiesOnShelf:int" は
   誘導フィールドで、必須ではない。
   Borrowingクラスが大きすぎないか、関連性が5本は多すぎ、
   またループになっている部分がある。
   図3.10 = ICONIX 図というらしい。ヤコプソンの
   ロバストネス分析に使用した。BCE図。
第4章
4.1 分析・設計に役立つ「パターン」
4.1.1 ソフトウェアパターンの由来
4.2 アナリシスパターン
4.2.1 「責任関係」パターン
  勘定について
  図4.5 なぜ金額が1行なのか、これはModelではないのか Viewでは貸し方、
  借り方分離で見ればいいのではないのか。
4.3 デザインパターン
4.3.1 Compositeパターン
　図4.8 右 {abstract}ステレオタイプの表記は良いのか？　
　せめて<<abstract>> か イタリック表記ではないのか。
　ホリモアフィズムの定義を知りたい、(宿題)
4.3.2 Observerパターン
4.3.3 Stateパターン
  Request()メソッドは get給料()の方がわかりやすいだろう。
4.3.4 パターンは活動である
　再利用率２０％の根拠は？　多分 CapersJones の
　ファンクションポイント計測屋さんの記事が出展ではないのか。

以上

[ 戻る ]