rcp-cm-01:概念モデル
目的
  • 対象業務に存在する概念（言葉）と概念間の関係を明らかにします
  • 対象業務を利害関係者が共通の概念（言葉）で理解できるようにします
  • 対象業務への理解を深めます
メタ情報
  • プロセス: 概念・用語整理
  • スコープ: 対象業務全体
  • 時点: ToBe
  • 視点: 対象業務には何があるのか（対象業務とは何か）
  • 記法: UML
  • ダイアグラム: クラス図
  • 作成単位: 対象業務全体/一部/特定概念（の周辺）
  • ツール: Enterprise Architect
 成果物関連

入力成果物リスト
前準備
  • 概念モデルの作成対象を決めます（業務全体、特定部分、特定概念等）
  • 企画や現状調査結果等、対象業務のあるべき姿（ＴｏＢｅ）に関する資料や情報を入手し、理解を深めておきます
  • ホワイトボードやモデリングツールを準備し、クラス図を作成できる環境を整えます
作成手順
No 作業 成果
1
  • 概念モデルの作成対象範囲を境界で表し、その中で中心となる概念（言葉）を最初に一つ或いは少数選び、クラスとして配置します。
2
  • 中心となる概念を起点に、関連する他の概念候補を洗い出し、主要概念の周りにクラスとして配置していきます。
  • この時、概念名（クラス名）を、その組織や関係者で使い慣れている言葉で表現するとより納得感が高まります。
  • 各種資料等に含まれていない暗黙の概念（言葉）も意識して洗い出すようにします。
3
  • 一通り概念候補を洗い出せたら、抽出した概念候補の中に、同じ意味を指すものや、異なる意味を一つの概念で表しているようなのものがないかを調べ、整理します。
    • 「購入」と「注文」等
4
  • 洗い出した概念候補に、以下のようなものがあれば整理します。
    • システムやその内部を表す概念⇒削除
      • 例：ＸＸＸデータベース
    • 業務ルールを表すもの（⇒ノートで表現しましょう）
      • 例：割引率の計算式、販売最大数等
    • 概念そのものではなく概念の別のビュー（見え方）⇒削除
      • 例：領収書、請求書（注文の別ビュー）等
    • 独立して存在できず、他の概念の属性となるべきもの
      • 例：名前、数量、日付等
    • 概念で行われる処理⇒削除或いはノートで記述
      • そのクラス（概念）の操作になりそうなこと
    • 対象業務において重要でない（細かな）概念⇒削除
      • 例：注文時に使うペン
5
  • ここまでで整理できた概念に、属性を追加します
    • 主要な属性だけ
    • 型や可視性を決める必要はありません
6
  • 概念と概念間の関係をクラス図の関連で表現します。
    • 関連は「関連端（ロール）名」と「多重度」で表現した方が、より正確性が増します。
  • 汎化・特化関係や集約・コンポジション集約の関係も必要に応じて活用しましょう。
7
  • ノートを用いて、概念や概念間の関係の意味、業務ルール、その他の補足事項を残しておきます。
ワンポイント・アドバイス
  • できる限り分かり易くシンプルに表現することを心がけましょう。
  • 概念モデルに「完成」はありません。利害関係者間で十分に対象ドメインを理解できる（できそう）と判断した段階で作成を終了しましょう。
  • 概念モデルにあまり厳密性を求めてはいけません。あくまで関係者間で理解することが目的です。厳密性を高めていくと、理解し難いモデルになっていく傾向にあります。
  • 作成手順No.5で、概念間の多重度が分かりにくい場合は、具体的な例をオブジェクト図で作成してみると明確になります。
チェック・ポイント
  • 作成対象における主要概念に関係する概念は漏れなく抽出できていますか？
  • 不適切な概念はありませんか？或いは概念として表現しようとしていませんか？
  • 利害関係者間で理解できる（できるだけ馴染みにある）言葉で概念を表現できていますか？
  • 利害関係者間で「同名意義」「異名同義」の概念は残っていませんか？
  • 概念モデルを分割して作成する場合、対象業務領域全体をカバーできていますか？
参考情報

※ソフトウェア年表もご覧下さい
お知らせ