■

第10章　問題領域モデル：概念の視覚化　続き(P145)

• オブジェクトの概念が必要（=概念クラス）
• 仕様または説明のためのオブジェクト「Xspecification」
• 「クラス」（=クラシファイア）の定義
• 概念的な観点と仕様的・実践的観点を区別することが大切

10.9 表現上のギャップの低減(P150)

Q：なぜ、ソフトウエアクラスの名前に問題領域の語彙を反映させるのか？
A：表現上のギャップが低減されるから

開発者はソフトウエアクラスを作成するときに、現実世界の問題領域から影響をうける。よって、利害関係者がどのように問題領域を認識するかということと、ソフトウエアでそれがどのように表現されるのギャップが減る。

問題領域モデルは、ソフトウエア設計における命名についてインスピレーションを与える元となる、問題領域の語彙および概念の視覚的な【辞書】でもある

Q:の部分は前に聞かれて明確に答えられなかった。「分かりやすいから」では納得してもらえなかった覚えがある。こう応えれば納得だよなー。上流工程とか下流工程って言葉は好きじゃないけど、なるべくドキュメントとか作りたくないけど、要件定義やってた人が、ソース見ても分かるとか、逆とかテストチームとか、やっぱりギャップをいかに減らすか、コミュニケーションだけではなく。

第11章　問題領域モデル：関連の追加(P157)

関連とは、「型や型のインスタンス間の関係」であり「インスタンスが接続されている二つ以上のクラシファイア間の意味的な関係」と定義される。

・ある期間、関連の情報を残しておくべき関連の識別を最優先にする
・「概念クラス」の識別の方が大事（関連の識別よりも）
・関連が多すぎると、問題領域のモデルが分かりにくくなる場合がある。（ほどほどに）
・冗長な関連や、推論できる関連は記述しない
・【情報把握】のための関連に重点をおく

• 表記法について
  • 慣習的に、左⇒右，上⇒下へと読む
  • 読み取り方向矢印は、図を読みやすくするためだけのもの

• 関連の発見に役立つ優先度
  • ＡはＢの「物理的または論理的な一部」　（A:Wing B:AirPlane)
  • Ａは「物理的または論理的にＢに」含まれる　（A:SalesLingItem B:Sale)
  • ＡはＢにおいて記録される　（A:Reservation B:FlightManifest)

• 役割について（関連のそれぞれの終端をrole（役割）と呼び、名前/多重度/誘導可能性のオプションを持たせることができる。

• 多重度の値からは、【ある特定の瞬間のインスタンスとインスタンスとが妥当に関連できるか】ということが分かる。何らかの時間にわたってではなく。多重度って問題領域の制約を伝達するものだから、ソフトウエアで反映される、されても良いから。⇒迷ったら！！！誰のために構築してるか考えると正しい観点で正しい多重度が決められるかも。（一夫一婦制の例や、中古車の例）

↓↓Craig Lerman　ラブ★

Q：問題領域モデルは、実装中に発見された洞察を元に更新すべきか？
A：『具体的に』将来使う予定がないなら、いらない。余計なことすんな！

■問題領域モデル=実装前の調査モデルだし、それは後のステップに【インスピレーション】を与えるに過ぎないから

■そして今はまだ、関連は純粋な概念的表現であると考える。設計についての考察を遅らせることによって、後々設計に幅が出る。