■

「理論上は,理論と実際に差異はない。しかし実際には確かに差異はある。---- Jan L. A. van de Snepscheut」
おっ。これなら実体験で知ってるぞ（笑

第9章 ユースケースモデル：システムシーケンス図の作成(P121)

• 「システム」シーケンス図は、ユースケースの主要な正常シナリオ、および、頻繁に登場する代替シナリオや複雑な代替シナリオのために作成する
• 「システム」シーケンス図は、ブラックボックステストとしてのシステムに適用していることを強調するために、ノーマルのシーケンス図とは区別をする。
• これにかける時間は30分程度で十分

• システムイベントを識別するには、システムの境界をどこに置くかを明確にする必要がある。
• システムイベントは、ソフトウェアを直接的に刺激する外部イベントである。
• システムイベントは、「何をしたいのか」という意図が伝わることが大事で、物理的な入力媒体やインターフェースレベルからの観点はいらない。
  • イベントおよび操作には抽象的な名前をつける（○：enterItem()　×：scan()）明確には述べず、抽象性が保たれているのに、操作の意図が明らか。

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

問題領域モデリングに不慣れな人にとって、この章は大事だって！！勝手にクレーグラーマンの弟子の気分になってるから、そうか重要かーって思っちゃう（笑

OOステップの真髄は、問題領域を自分たちが知っている個別の概念クラスやオブジェクトに分解していくこと。

問題領域モデルとは、現実世界の概念クラスを表現するもの。まだソフトウェアのクラスまたはオブジェクトを説明する図ではない。

また、ユースケースはOOの成果物ぢゃない。問題領域をプロセスの視点から考察するもの。

• domein model（問題領域モデル）※一般的な概念　は下記と同意義で使われる。
  • Domain Model（UP問題領域モデル）
  • conceptual model（概念モデル）
  • domain object model（分析オブジェクトモデル）

• 問題領域モデルとは、他の手段でも表現できることを視覚的に表現したもののこと。（抽象概念，問題領域の語彙など視覚的な辞書である）
• 問題領域モデルは、ソフトウェアの成果物やクラスを視覚化するのではない。
  • ○：Saleクラスでdateとtimeプロパティを持つ（現実世界の視覚化）
  • ×：SalesDatabase（ソフトウェア成果物）
  • ×：Saleクラスでdateとtimeプロパティとprint()を持つ（ソフトウェアのクラス）

• 【概念クラス】
  • シンボル：概念を表すことばやイメージ
    • （例）Saleクラスでdateとtimeプロパティを持つ
  • 内包(intension)：概念の定義
    • （例）saleは購入取引のイベントを表す。これは日付と時刻をもつ。という記述
  • 外延(extension)：その概念を適用できる例の集合
    • （例）sale-1，sale-2，sale-3の集合

分析における最も重要な仕事は、問題領域のさまざまな概念を識別し、結果を問題領域モデルとして文書化すること。
※難しいから、分解して複雑さを克服しよう！
※オブジェクト指向分析と構造化分析の主要な違いは、概念クラス（オブジェクト）で分割するか、機能で分割するかという点にある