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

[ 戻る ]


「 UML モデリングの本質」を読む会第3回議事録
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 パターンは活動である
 再利用率20%の根拠は? 多分 CapersJones の
 ファンクションポイント計測屋さんの記事が出展ではないのか。

以上


[ 戻る ]