[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 11329] Re: 「 UML モデリングの本質」を読 む会第３回議事録

根本さん、上手です。
コメントです。

> 本日の議事録をUPします。
> ついでに、
> 宴会時に話した、英語dialogueのmp3のdownload出来るサイトはwww.loe.orgです。
> 村上さん、ついでに、MSのmp3サイトのURLもお教えください。
> 根本
> -------------------------------------------------------------------
> 
> 「 UML モデリングの本質」を読む会第３回議事録
> 2004年 8月21日
> 出席者
> 　高橋(徹) 村上 上手 吉村 根本 村山 松本 金 中村 大仲 西野 山口
> 　吉本 岩永 戸田 大江 中原 高橋(智) 石黒 遠藤 根本(記)　　敬称略
> 
>   p93 第3章より
> 概念レベルから実装レベルへ
> 3.1 概念レベルのクラス図を実装レベルに変換する。
> 　プロジェクト管理におけるフェーズとは何?
> 　単なるウォーターフォールでいうフェーズのことか？
>   (4)動的分類を実装で扱える形にする。
>   この設計でいいのか、
>   StatePatternをつかうべきか enum でいくべきか？
>   テストの容易性ではPattern-wg的思考では、
テストの容易性では　＊8月のPattern-wgの勉強会でIBMの大田さんより発表のあっ
たテストパターン＊　的思考では、
>   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" の本が副読本に適切、海運業界の実装例が載っている。
Eric Evansの"Domain Driven Design" の本はドメイン領域のモデルを書くには
評判が良いようだ。海運業界のモデリング例で構成されている。
>    P117 図3.13 Bookクラスの "/copiesOnShelf:int" は
>    誘導フィールドで、必須ではない。
>    Borrowingクラスが大きすぎないか、関連性が5本は多すぎ、
>    またループになっている部分がある。
>    図3.10 = ICONIX 図というらしい。ヤコプソンの
>    ロバストネス分析に使用した。BCE図。
図3.10 = ICONIX 図というらしい。
ヤコプソンがObjectoryプロセスで提唱したロバストネス分析（RUPには入らなかっ
た）をコンサルタントのローゼンバーグとケンドール・スコットが実装したのが
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 の
> 　ファンクションポイント計測屋さんの記事が出展ではないのか。
出展ー＞出典
> 
> 以上
> 　
> 　
>