はじめに
本記事は、経験の浅いエンジニアを対象とした記事になります。
今回は、概念モデリングについての紹介です。
下記観点からの理解につながれば幸いです。
- What 概念モデリングってなに？
- When 概念モデリングは、どのタイミングでやるのか
- Why なぜ概念モデリングをやるのか
- How 概念モデリングのやり方（概念モデリングをやってみよう！）
目次
| 章 | タイトル | 概要 |
|---|---|---|
| 1 | 概念モデリングってなに？ | 概念モデリングの基本的な考え方について紹介します。 |
| 2 | 概念モデリングは、どのタイミングでやるのか? | アプリケーション開発のどの段階で、実施するのか紹介します。 |
| 3 | なぜ概念モデリングをやるのか | 概念モデリングの目的や意義について紹介します。 |
| 4 | 概念モデリングをやってみよう！ | 実際に概念モデリングをやりながら、実施していく際のポイントを紹介します。 |
1.概念モデリングってなに？
結論、概念モデリングとは、「システムの静的な構造」もしくは「データの構造」を表したものになります。
前回紹介したユースケース分析を思い出してみてください。
ユースケースを記述する際に、「会員」、「注文」、「決済」、「配送」など、さまざまな概念が出てきたと思います。
そのさまざまな概念の意味や概念の詳細、概念の関係性（一対多、多対一）を明確にしていくのが概念モデリングになります。
概念モデリングのやり方は後述しますが、概念モデリングをやる際の基本的なことは下記の３つになります。
・概念の名前を整理する
・概念の関連を整理する
・概念の関連の多重度を整理する
この３つを明確にしていく作業が概念モデリングです。
※概念・・・大まかな意味や内容のこと。（例：りんごの概念・・・赤くて丸くて甘い味がする果物）
2.概念モデリングは、どのタイミングでやるのか？
結論、要件定義のフェーズもしくは、外部設計のフェーズでやります。
概念モデリングは、前回のユースケース分析と同じように、要件定義のフェーズか外部設計のフェーズでやります。また、ユースケース分析にて登場した概念をもとに、概念モデリングを行うので、ユースケース分析を行った後に実施するケースが多いそうです。
3.なぜ概念モデリングをやるのか。
結論、下記のようなメリットがあります。
・業務やシステムの機能の大枠を知ることができる
・システム全体のデータを一元的に見ることができる
・ユーザー企業との、データ構造における認識の齟齬をなくすことができる。
・データベース設計の際に、役立つ
概念モデリングは、主要な概念、データのみで構成されており、細部まで厳密性を持って表現することはない「遊び」のある表現手段になりますので、業務やシステムの機能の大枠を知ることに繋がります。
そして、システム全体の概念やデータの関係性を一つのドキュメント上にまとめて表現するため、一元的に見れます。
また、「一対多」、「多対一」などのデータの関係性を明確に表現した概念モデリングは、この後のフェーズで実施するデータベース設計のテーブル、レコード、データの関係性を考える上で大きく役に立つ材料であるとも言えそうです。
4.概念モデリングをやってみよう！
では実際に概念モデリングをやってみましょう！
※概念モデリングは、完璧な表現記法ではありません。
関連性、構造を中心に表現しただけであり、システムやデータについての全てを表現したものではありません。
また、同じシステムの概念モデリングでも人によって書き方が違ったりします。
概念モデリングをやる際に作成する代表的なドキュメントは下記になります。
・概念モデリング図
今回は、前回に引き続き大手ECサイトの楽天市場を例に、概念モデリングを行ってみます。
まず概念モデリングではUMLクラス図で記述します。
UMLクラス図は対象のシステム内に存在する要素を1〜３行からなる長方形に図式化したものになります。
（ UMLクラス図を書く際の細かなルールについては、ここでは割愛します。）
次に概念モデリングでやらないことを紹介します。やらないことは下記になります。
・intやStringといった属性の型はつけない。
・操作は書かない
次に概念が何か、ユースケースを元に洗い出します。
今回の例の楽天市場では、下記のようになるかと思います。
・商品
・商品名
・商品単価
・商品数量
・商品説明
・注文
・注文合計金額
・注文番号
・注文日時
・会員
・配送先
・配送日時
概念が何か洗い出したところで、次は実際にクラス図を書いていきましょう。
とりあえず会員を置いてみましょう。
次に注文を置いてみます。
注文を置いたら、会員との関係性を考えます。
楽天市場では、１人の会員がたくさんの注文をすることが可能です。
逆に１つの注文をたくさんの会員ですることはできません。
そうなると会員と注文の関係は一対多の関係であると言えそうです。
上記を踏まえて記述すると下記になります。
一対多の一の方に１、多の方に0...❇︎を記載します。(「0...❇︎」は注文の数が「最小で０個、最大でたくさんの数（際限なし）」を表現しています。）
次に注文繋がりで、注文合計金額、注文番号、注文日時を置いてみましょう。
まず、注文合計金額は一つの注文に備わる属性の内の一つと考えることができます。ですので注文と注文合計金額は一対一の関係であり、注文合計金額は注文の属性であるということから下記のような表現になります。
また、同じように注文番号と注文日時も、注文の属性の内の一つであり、一対一の関係になることから下記のようになると思います。
次に配送先を置いてみましょう。
楽天市場では、一人の会員が、複数の配送先を登録しておくことができます。
なので会員と配送先の関係は、一対多と言えるでしょう。
また、注文との関係についてですが、１つの注文に１つの配送先を結びつけるという観点から、配送先を注文の属性の内の１つとするパターンと、複数の注文をし、その注文全てに１つの配送先を指定できるという観点から、注文と配送先を分けて表現するというパターンもあります。
ここでは後者のパターンで表現します。
次に配送日時を置いてみましょう。
配送日時は、１つの注文に対して１つ設定するという観点から、注文と配送日時の関係は一対一であると言えます。
また配送日時は、注文を確定させて購入に進むときに設定し、注文合計金額などと一緒に確認画面に表示されるものなので、注文の属性とも言えそうです。
以上を踏まえて下記のように表現しました。
次に商品と商品名、商品単価、商品説明を置いてみましょう。
まず商品名、商品単価、商品説明は、商品の属性であり、一対一の関係であると言えそうなので、下記のようになると思います。
そして、注文と商品の関係性は一対多であり、「注文と商品」は「全体と部分」とも言えそうです。
クラス図で「全体と部分」を表現する場合、コンポジションと呼ばれる黒い菱形と矢印を使って表現します。
コンポジションを使って今回の商品と注文の関係性を表現すると下記のようになりました。
最後に商品数量を置いてみましょう。
商品数量は、注文に関するものであり、注文と商品数量の関係性は、先ほどと同じ「全体と部分」の関係に該当すると考えられます。
また商品数量と商品は、商品数量の数がいくら増えても、その商品数量が参照する商品は１つに絞られるので、多対一の関係であると言えそうです。
これらの点を踏まえるとこのような表現になるかと思います。
以上で前回の記事のユースケースで出てきた概念は、概念モデリングによって整理されたかと思います。
今回、楽天市場をもとに概念モデリングを行いましたが、まだまだ表現されていない概念がたくさんあるかと思います。興味がある方は、まだ出てきていない概念を置いて、あらゆる関係性を概念モデリングで表現してみてはいかがかと思います。
（注文明細という概念を置いてその属性に商品数量や明細価格を設定したり、決済の概念を置いたり、出店店舗の概念を置いたりなどなど。。。）
まとめ
概念モデリングは、ユースケース分析にはない、「システムで使われる概念の意味や関係性を整理する」といった観点から、システムへの理解を深めることができる便利な考え方です。
ユースケース分析と概念モデリングの両方を合わせて使うことで、対象のシステムを「システムの振る舞い」と「システムが持つ概念やデータの構造」のふたつの面から見ることができ、新たな発見に繋がりそうです。
また今回、紹介した概念モデリングは、ユースケース分析と同じく、あくまで一例にすぎず、明確なルールなどはありません。
参画するプロジェクトによって細かいやり方やルールは変わりますので、ご注意ください。
今回学習の参考にした書籍は下記になります。
設計の基本を知らなくても理解できる内容になっております。
次の記事は、「データベース論理設計」についての執筆を予定しています。
拙文最後までお読みいただきありがとうございます。
Discussion