[jfriends-ml 11306] 議事録 UML モデリングの本質 第２回 (案)

["y-kamite" <y-kamite@xxxxxxxxx>]

上手です。
遅くなりましたが、議事録案です。コメントお願い致します。
-----------------------------------------------------------

議事録 UMLモデリングの本質 第２回(案)
日時  ：04/07/31  
場所  ：川崎市　武蔵小杉

出席者（座席順）合計２２名
＃過不足が有るかもしれません。

家永、宮本、坂本、西野、片平、深津、山下、遠藤、大崎、吉村、
高橋（智）、中村、根本、東川、高橋（徹）、
村山、村上、角田、上手、吉本、家永、鈴木

読上：西野、高橋（智）、中村　書記：上手

10:05- 開始
       自己紹介

10:20- 読書開始

Q　P54L(行)3　「破線のグループ化」は、UMLの仕様？
A  そのようだ

Q　P53図9　クラス「顧客」の中に「重要顧客」のインスタンスAがあるのはあいまいでは？
Q　クラス「顧客」の中に（補集合のインスタンス）Eがあればいいという質問か？
A  オデール（Odell)のクラス図の記法を下敷きに話しているようだ。
　 クラスの内部に完全区画、不完全区画（補集合のないもの）が書かれる。

Q　2.2.7　型とクラスの違い、の3行目、
　「全ての属性や操作を明示しているわけではない」の意味は？
A　分析の話では？
A　型の方が範囲が広い
A　UML以外の（別のオブジェクト指向モデリングの）知識を前提にしている議論のようだ。

Q　P61の名刺抽出法以外の方法はあるのか？
A　名刺抽出法は、かなり古い手法だ。
A　CRCカードとかポストイットのKJ法などもある。
A　名刺抽出法だと、エンティティ（モデル）でなく、ビューばかり出てきてしまう。

Q　ユースケースとモデリングはどちらが先？
A　ドメインモデリングの方が先では？
Q　ドメインって？
A　問題領域と訳すのが定番

Q　要件定義のキーマンはどうやって見つけるの？
A　皆がその人の発言を引く（参照）ような人
A　KJ法なんかやっている時に主導する人

Q　大きなシステムのクラス数は？
A　数千位はいくのではないか。
A　分析（エンティテイレベルと、MVCレベルの２つ）、設計、実装レベルで異なる
A　メトリクスも重要だ。OGISで提供していたJMAなどで測れる（平澤作？）
A　Eclipseのプラグインのマッケーブ（循環的複雑度を測る）もある。
http://www.linkclub.or.jp/~tumibito/soft-an/metrics/mccabe.html
http://eclipsewiki.net/eclipse/index.php?%A5%E1%A5%C8%A5%EA%A5%AF%A5%B9%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3
http://kino.mine.nu/pukiwiki/index.php?Java%2F%A5%BD%A1%BC%A5%B9%A5%B3%A1%BC%A5%C9%A4%CE%B9%D4%BF%F4%A4%F2%BF%F4%A4%A8%
A4%EB

Q　図2-16　XORの破線の意味は　
A　−＞宿題

Q　P64L15　スーパークラスを設ける度に、このことを確認する習慣・・・の意味は？
A　親クラス間の関連は子クラスにも継承される、ので、どんどん関係が広がっていく。
　 つまり、スーパークラスを導入してきれいなクラス図にすると、
　 細かな条件が飛んでしまうので注意しよう。ちゃんと制約に書いて残しておこう、ということ。

Q　下からL2　「ノートで書く」というのは？
A　後でちゃんと制約で書き直すのだろう。

Q　P66L4　<<動的>>ステレオタイプは、著者独自の用語？
A　−＞著者に聞く

Q　P66L最後　ロールをクラスにすると一つのオブジェクトが複数のクラスの属する、とは？
A　教職員が夜は学生になる、といった例が考えられる

Q　P68　注10　XORはいるのか？
A　必要。無いと、一つの貸し出しが、２つの会員と関連がある事例が発生してしまう。
A　慣れた人にとっても、クラス図は微妙な問題が発生して、難しい。

Q　P70で、ユースケースについて、「方法の一つが目的の階層構造をつくることだ」
　 という記述があるが、これは何がいいたいの？
A　要求を分析する際に、ユースケースに目的ベースの構造や階層化を盛り込めということでは
　 ないか。
A  確かに、P71のユースケース図を見ると、図書館システムは「事務員向けシステムだ」とわかる。

Q　ユースケースの管理はどうしているのか？
A　顧客に承認をもらうものだけ、版管理している。
A　コーバーンのユースケース本の、海面の部分まで管理している。
A　開発部門の内部ユースケースは、きちんと管理はしていない。
A　粒度をそろえることも大事だ。

Q　ユースケースは必ずつくるのか？
A　どんな形でもいいのではないか。
A　DBCスタイルのユースケースはMeyerが提唱したDBC（契約による設計：Desighn By Contract)
　 がユースケースに取り入れられたもので、厳密に要件を定義しようという主張。
Q　P84L下から４　「もの--こと--もの」とは？
A　P48参照。
A　ことはイベントかな
A　マスター　--　トランザクション　--　マスタかも。

（この項は休み時間の会話）
Q　P89の図2-33　駅--運賃--乗車券、のモデルは冗長な感じ。重複した線が多すぎる
A　運賃計算って、単なる機能のような気もする

Q　多重分類はどこから来てるの？
A　制御系の大家の手法、シェラーメラー法から。

次回、溝口　8/21
（以上）