概念モデルという概念が何かをまとめる

概要

アナリシスパターン^[1]などの本を読むと出てくる「型図」「概念モデル」「ドメインモデル」「クラス図」の定義・使い分けがよくわからなくなってきました。
そこで、少し調べてまとめてみました。

↑こんな感じの図

概念モデルとは

調べてみると、stackoverflow にわかりやすい図がありました。
stackoverflow - What is the difference between a domain class diagram and a design class diagram?

画像にCC-BY とあったので、こちらにも貼っておきます。

Gerd Wagner さんの同様の図を使っている論文もありました。
Gerd Wagner (2018), Information and Process Modeling for Simulation – Part I

これに則ると、

• 概念モデル（＝ドメインモデル）＝ソリューションに依存しないように書かれたクラス図
• 概念情報モデル＝型＋属性の概念モデル
• 概念処理モデル＝型＋属性＋関数の概念モデル

ということになりました。

型図

アナリシスパターンの p.37 に次のようにあります。

あるものが属性なのか関連なのかを何が決めるのかということである。（中略）概念モデルではどちらの方法でモデリングしてもかまわない。（中略）筆者は属性か対応付けかを区別していない

アナリシスパターンで扱っている概念モデルは上の定義でいうと「概念情報モデル」にあたります。
このような 属性と対応付けを区別しない概念情報モデル図 のことを「型図」と呼ぶことにしました。

実際の開発では、型と属性を使って「型図」をとりあえず作成し、それを変形することで型と属性の関係性に多少の意味を持つ「概念情報モデル」が作成されるのをイメージしています。

ドメインモデル

上では「ドメインモデル＝概念モデル」としましたが、モデルベース要件定義テクニック^[2]にて少し違う記述を見つけました。
要点は以下です。

• システム要件は以下の4つのステップで捉えられる
  • システム価値
  • システム外部環境
  • システム境界
  • システム
• 上から順にシステムの内側へとフォーカスしていく
  • 内側は外側へ依存する
• 概念モデルは システム外部環境、ドメインモデルは システム に属する

つまり、概念モデルはシステムの外側、ドメインモデルはシステムの内側に属するとしていました。
確かに、オニオンアーキテクチャなどの図でもドメインモデルが中心となるものがあったので、この説明はとても納得できました。

まとめ

現時点では、次のように捉えることにしました。

• 概念モデル（概念情報モデル）
  • システムの外側における概念の関係性を表したもの
  • 業務に強く結びつき、システムが無い世界でも存在する
• ドメインモデル
  • システムの内側における概念の関係性を表したもの
  • 業務に強く結びついているが、システムで実現可能なものになっている
• 型図
  • 属性と対応付けを区別しないモデル図
• 概念モデルとドメインモデルはシステムの内側と外側の違いなので、深く関連性がある
  • 場合によっては、全く同じになる

この記事は 2020年5月20日に Qrunch にて公開していた記事を元に修正したものです

脚注

1. Martin Fowler (2002) アナリシスパターン: 再利用可能なオブジェクトモデル, ピアソンエデュケーション

2. 神崎善司 (2013) モデルベース要件定義テクニック, 秀和システム