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

議事録 UMLモデリングの本質第２回
日時  ：04/07/31
場所  ：川崎市　川崎市中原市民館第3会議室

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

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

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

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などで測れる
（補足）URLは以下です。
http://www.ogis-ri.co.jp/otc/hiroba/others/JavaMetricsTool/JMA.html

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（排他OR）の破線の意味は
（回答）高橋徹
UML1.5の仕様3.42.5.1 Xor-association に記述されています。
"An xor-constraint indicates a situation in which only one of several
potential associations may be instantiated at one time for any single
instance.
Xor関連は幾つかの可能な(potential)関連があっても、一度には一つの関連しか
実現(instanciate)しないことを示します。
This is shown as a dashed line connecting two or more associ-
ations, all of which must have a classifier in common, with the con-
straint string "{xor}" labeling the dashed line.
関連をダッシュ線（破線）で結んで、"{xor}" のラベルをつけます。
Any instance of theclassifier may only participate in one of
the associations at one time.
Each rolename must be different.(This is simply a predefined use of
the constraint notation.)"

UML1.5仕様書
http://www.omg.org/cgi-bin/doc?formal/03-03-01

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
（以上）

[ 戻る ]