出席者(座席順)合計22名#過不足が有るかもしれません。オデール(Odell)のクラス図の記法を下敷きに話しているようだ。(補集合のないもの)が書かれる。UML以外の(別のオブジェクト指向モデリングの)知識を前提にしている議論のようだ。名詞抽出法は、かなり古い手法だ。CRCカードとかポストイットのKJ法などもある。名詞抽出法だと、エンティティ(モデル)でなく、ビューばかり出てきてしまう。数千位はいくのではないか。OGISで提供していたJMAなどで測れる(補足)URLは以下です。Eclipseのプラグインのマッケーブ(循環的複雑度を測る)もある。singleinstance.Xor関連は幾つかの可能な(potential)関連があっても、一度には一つの関連しか実現(instanciate)しないことを示します。親クラス間の関連は子クラスにも継承される、ので、どんどん関係が広がっていく。細かな条件が飛んでしまうので注意しよう。制約に書いて残しておこう、ということ。後でちゃんと制約で書き直すのだろう。無いと、一つの貸し出しが、2つの会員と関連がある事例が発生してしまう。慣れた人にとっても、クラス図は微妙な問題が発生して、難しい。要求を分析する際に、ユースケースに目的ベースの構造や階層化を盛り込めということではないか。確かに、P71のユースケース図を見ると、図書館システムは「事務員向けシステムだ」とわかる。顧客に承認をもらうものだけ、版管理している。コーバーンのユースケース本の、海面の部分まで管理している。開発部門の内部ユースケースは、きちんと管理はしていない。粒度をそろえることも大事だ。どんな形でもいいのではないか。Contract)がユースケースに取り入れられたもので、厳密に要件を定義しようという主張。